8-channel Renard Servo Controller

[omzig]

I've been working on a Renard servo controller...

In summary, this board will control up to 8 RC servos using the Renard protocol and the same Renard Vixen plugin. It can be placed in a Renard chain and it will otherwise perform just like any Renard light controller. It will take packets destined for it, and translate the dimmer levels into servo positions.

Each servo will have 3 configurable modes of operation which are; Standard, Extended, and Disabled.

In the Standard mode, the Renard dimmer levels will be translated to control pulse widths in the range of 1ms to 2ms. A dimmer level of 0 would produce a 1ms pulse, 255 would be 2ms, and values in between would produce widths proportionately between 1ms and 2ms. This makes the increment for each dimmer level approximately 3.9µs. This range will work with a majority of servos.

In the Extended mode, the dimmer levels will be translated into pulse widths of 0.5ms to 2.5ms. A dimmer level of 0 would produce a 0.5ms pulse width, 255 would be 2.5ms, and values in between would produce widths proportionately between 0.5ms and 2.5ms, in approximately 7.8µs increments. This mode allows you to use an extended control range that some servos support.

When a servo is disabled, no pulse will be generated and any dimmer data for it will be ignored.

***EDIT***decided to do this in hardware***Using the current Renard plugin does pose one problem...how to allow the user to specify the mode of operation setting for each servo. I plan to store these settings on the PIC's EEPROM, which will then be loaded during the initialization routine. But there still has to be a way for the user to specify these settings. I thought of a few different ways to accomplish this. The method that I prefer is to use command bytes within the Renard protocol that are <0x80. The current Renard firmware just forwards packets with command bytes <0x80. I could write a small Windows program to send the configuration commands.

Another method for setup that I thought of is to have a "program mode" jumper on the board that would put the board in a programming state. Then any protocol could be used to send the settings to the board. Pin 4 could be used for the jumper since there is no need for a zero cross signal on this board.

I am attaching the schematic. I will post the firmware soon. I am going to try to breadboard it this weekend. Any comments are welcome.

[ukewarrior]

Don,

I vote for the 'mode' to be set with a jumper or dip switch. With proper silkscreening, this jumper could be self explanatory. Plus, you'd only need the jumper for two of the settings. Have a 'no jumper' be one of the settings and this is what the pic code defaults to unless it reads a 'one' on one of the jumpers. This way it always works incase someone doesn't have a jumper handy.

I certainly vote against doing it in the PIC. No one wants to reflash a pic if they don't have to.

I also vote against doing it with command packets. Elegant, but I don't want any more software to keep track of.

Neat Stuff. I love the fact you are reusing so much of existing infrastructure. I suggest you keep it that way!

[omzig]

I certainly vote against doing it in the PIC. No one wants to reflash a pic if they don't have to.Not sure what you mean here. I only propose writing the settings to the PIC's EEPROM from within a setup routine in the firmware. No reflashing with a programmer would be required.

[ukewarrior]

oops.
Gotcha.
So, I guess my vote is to read those settings off jumpers during initialization.

Again, very nice stuff.

[scorpia]

you could also use a 9th and maybe 10th channel and have those bit values set the 8 channels of the servo's. it could then be changed at any time by simply changing the channel value.

would be a channel wasted most of the time but it would allow this to be done without any hardware changes or plugin changes,

for example use channel 9 as the on or off channel and the 10 channel could set standard or extended modes,

being 8 channels and 8 bits makes it easy

Peter

[djulien]

Using the current Renard plugin does pose one problem...how to allow the user to specify the mode of operation setting for each servo. I plan to store these settings on the PIC's EEPROM, which will then be loaded during the initialization routine. But there still has to be a way for the user to specify these settings. I thought of a few different ways to accomplish this. The method that I prefer is to use command bytes within the Renard protocol that are <0x80. The current Renard firmware just forwards packets with command bytes <0x80. I could write a small Windows program to send the configuration commands.

If you didn't want to make any changes to the plug-in, the controller firmware could be made to consume one extra channel at the beginning of its block of channels, and use that as a "configuration byte". Then you could set this config channel to whatever binary value is needed using Vixen's Intensity function (maybe a 1, 2 or 3 to set one mode for the entire controller, or use additional bits to control the mode for individual servo channels). Except for those special Renard byte values that get translated/escaped, a little binary arithmetic should allow you to send any config byte value needed, which would allow complete configuration under software control. Software config might be more convenient than going out in the cold and digging some snow if you ever have to change the config after the display is set up.

don

don

[omzig]

Peter and Don, your ideas are very similar. I like this approach a lot. *smacking forehead* Why didn't I think of that?

I think that one "control channel" would be plenty. I'm wondering if rather than adding an extra channel, it might be better to make it a 7 servo controller and then only 8 channels would be needed. While the code for this board could certainly be modified to steal an extra channel when using long form packets, I'm thinking that it may not work well with short form packets because eight bytes are expected after each command/address byte. This would kind of mess up the backward compatibility of the firmware. I will have to have another look at the standard firmware to verify this, but the way I recall it, this would be the case.

Not to mention, I think that the user is less likely to forget to add the control channel to their Vixen sequence if the board were to use 8 channels than if it were some odd number like 9. Forgetting to add it would definitely make a mess of things because the board would take the channel anyway, which should be a channel for the next controller.

Thanks for the idea Peter and Don!

[djulien]

I think that one "control channel" would be plenty. I'm wondering if rather than adding an extra channel, it might be better to make it a 7 servo controller and then only 8 channels would be needed. While the code for this board could certainly be modified to steal an extra channel when using long form packets, I'm thinking that it may not work well with short form packets because eight bytes are expected after each command/address byte. This would kind of mess up the backward compatibility of the firmware. I will have to have another look at the standard firmware to verify this, but the way I recall it, this would be the case.

Seven channels is very nice if you are using cat5 and want to pack it full of signals and a +5.

I had forgotten about the protocol using multiples of 8 bytes, but that does sound vaguely familiar. In order to preserve multiples of 8, you could either pad up to 16 bytes, which wastes a little of the Renard address space, or you could just steal a few bits from the 8 channels. For example, if you used the top or bottom bit from at least 2 of the channels, that would give you enough to set a controller-wide 1-of-4 mode. If you used top bits, then the channel intensity values for normal use would need to be < 128, and then add 128 or 192 or whatever to set the config. If you used bottom bits, you would need to adjust for odd vs. even values, etc. Still a bit awkward, but doable if you are good with binary arithmetic.

Or, you could use a byte pattern scheme. For example, maybe use the first byte in the group after a long interval of 0s to be used as the config byte, or maybe right after a frame containing all 85s or 170s use the first byte from the next frame as the config byte. Presumably that would only need to be set once at the start of the sequence, which isn't so bad.

You could also do something like designate values 1, 2 and 3 from the first channel as the mode control. Since LEDs and incandescents don't visibly change in the upper and lower 20%, the values in those ranges are not too useful. For servos they probably would be, but maybe they wouldn't be missed on, say, the first 1 of the 8 channels.

Or, you could do something like make 7 of the channels dimmable, and the 8th channel is just on/off or maybe reduced range, and then use the spare bits from that to be the mode control.

don

[prof]

If you are going to use vixen to set the operating mode, is there some reason why you cannot have each of the 8 channels read their own independant mode setting from their corresponding vixen channel - no wasted channels that way. In view of this, how about having an additional mode (ie zero) to 'keep existing channel setting' that way you only need to reprogram the channels you require.

Craig.

[omzig]

If you are going to use vixen to set the operating mode, is there some reason why you cannot have each of the 8 channels read their own independant mode setting from their corresponding vixen channel - no wasted channels that way. In view of this, how about having an additional mode (ie zero) to 'keep existing channel setting' that way you only need to reprogram the channels you require.

Craig.Actually, this is kind of what I was just thinking about. Using the first few bytes of the sequence for each channel for setup of that channel. Probably start it with some unlikely pair like 0xff 0x00 to indicate a setup byte is coming, otherwise the first few bytes would be ignored and the default settings would be used.

[ppohlman]

I can't believe that I missed this thread earlier. I've been anxiously awaiting to hear more about omzig's progress on the Renard Servo Controller. It's looking pretty good thus far.

One suggestion I have is to connect the 7/8 pins on both of the IN and OUT RJ45 sockets together. Even though this board will not be using Zero Crossing, it would be nice to pass it along the line. This way you can connect other light controllers down-stream and still be able to dim lights after it.

[omzig]

One suggestion I have is to connect the 7/8 pins on both of the IN and OUT RJ45 sockets together. Even though this board will not be using Zero Crossing, it would be nice to pass it along the line. This way you can connect other light controllers down-stream and still be able to dim lights after it.Good point. I will do it.

[omzig]

Thanks for the suggestions for handling the channel configuration. I've thought a lot about the best way to do this, and this is what I've come up with:



All servos will start out disabled. Once any data is received for a channel, that channel will be enabled and its control pulses will start.
If the very first byte of data received for a channel is 0xFE (254) that channel will be set up in the extended mode (and the 0xFE will be discarded). If the first byte is any other character, the channel will be in the standard mode. Once in the extended mode, a channel will remain extended until the controller is reset.


I think that this is the simplest approach, but it is still effective. If you aren't using any extended range servos, the you don't have to do anything as far as configuration is concerned--just start sending data.

In the unlikely event that you would want a 254 for your first position in the standard mode, you could use a 253 or 255 first, and then 254. Being off by 1 for a duration of one Vixen timing interval is hardly going to be catastrophic. If you needed you first position to be 254 in the extended mode, you could just use two consecutive 254's.

Comments?

[omzig]

The more I think about it, I don't like the idea of stretching the Renard protocol to handle the extended mode configuration. I would rather do it with jumpers on the board. This requires more pins though, so I'm looking at using the 20-pin 16F687 instead of the 16F688. The new schematic is attached.

[P. Short]

There are ways of adding jumpers that do not require extra pins, basically by re-using existing pins. For example, you could add a jumper to ground on an output pin that would normally be pulled up. At power-up you tri-state the output and use it as an input. If you detect that the pin is tied to ground, do the special stuff, and if you detect that it is not shorted to ground, re-configure the pin as an output for normal use.

[omzig]

There are ways of adding jumpers that do not require extra pins, basically by re-using existing pins. For example, you could add a jumper to ground on an output pin that would normally be pulled up. At power-up you tri-state the output and use it as an input. If you detect that the pin is tied to ground, do the special stuff, and if you detect that it is not shorted to ground, re-configure the pin as an output for normal use.Interesting...But if the jumper is in place, how do you then use it as an output if it is shorted to ground?

[scorpia]

I suppose really you the ideal option would be to use the "command" protocol options phil built into the protocol. (remember the double 127 byte issue)

the biggest issue with that is the current plugin's dont support them.

I just keep coming back to thinking "jumper's for configuration is just so 90's" :)

anyway. just another idea. at the end of the day it is your design and you need to do what you feel happy with. if other dont like what you do they just wont use it. either way you still get a controller that works for you.

[omzig]

I just keep coming back to thinking "jumper's for configuration is just so 90's" :)LOL...Yeah well I'm kind of an old-fasioned kind of guy.



anyway. just another idea. at the end of the day it is your design and you need to do what you feel happy with. if other dont like what you do they just wont use it. either way you still get a controller that works for you.Yeah I know. But I still value the opinion of the community. My reason for doing the board is mostly for myself, because I have an idea for using servos this year. I know Frank said he used DMX for this, but since I don't have any other DMX stuff (that is, unless I get around to building the Pixel boards that I bought), and there is going to be a Ren24 right by where I need the servos, it just seems the easiest way to go, especially since it's >100' from the computer. Not to mention that I'll have a ton of fun doing it (probably the biggest reason). If someone else has a use for the board, then that's great too. Actually, a couple of people have already expressed interest.

[WireNut]

I found this last week and have built the circuit included. It seems to work as advertised.
The only input needed is servo number (1-8) and position. IE: 1,175
http://www.rentron.com/SerialServo.htm

My question is could this be controlled by Vixen. It seems to me only a plug-in would be needed to convert the channel number to the servo number and the dimming level to the range (20-220). Or am I missing something.

[omzig]

I found this last week and have built the circuit included. It seems to work as advertised.
The only input needed is servo number (1-8) and position. IE: 1,175
http://www.rentron.com/SerialServo.htm

My question is could this be controlled by Vixen. It seems to me only a plug-in would be needed to convert the channel number to the servo number and the dimming level to the range (20-220). Or am I missing something.Sure a plugin could be written to do that. A plugin could be written for just about any serial servo controller. My design is trying to make a controller that works within any Renard chain, and doesn't require another interface to the host or any software changes. That is the topic of this thread.

[WireNut]

I didn't intend to steal your thread. I like your Idea and hope it works I to have Renards and would like to use servos as well.
Sorry bout that.
Ric

[omzig]

I didn't intend to steal your thread. I like your Idea and hope it works I to have Renards and would like to use servos as well.
Sorry bout that.
RicNo problem Ric. Sorry, I sounded a bit harsh. If you decide to try to use that controller, I'd be happy to offer any assistance that I'm able to.

[chilloutdocdoc]

Really liking the sound of this board, if there's anything i can do to help (or if you just need a guinea pig, let me know)

[omzig]

Really liking the sound of this board, if there's anything i can do to help (or if you just need a guinea pig, let me know)This project is still active, but I have been a little busy as of late. g2ktcf has had some good ideas and has also been working on it. We may need a guinea pig or two then we get a working prototype.

[ppohlman]

I've been anxiously awaiting more news about this project. I'm glad to hear that it isn't dead. I was almost ready to send you a PM, omzig, just to see what's been going on recently.

[eswets]

I've got great interest in this board also. anything we can help with let us know. Thanks for all the hard work with this.
Eric

[omzig]

As soon as I get the Renard SS group buy finished, I'll get back into this and bring this thread up to speed on the changes.

[chilloutdocdoc]

No rush at all. We all realize, or attempt to, the amount of work that goes into designing and developing a design, not to mention doing it while running a group buy.

[ErnieHorning]

Using the current Renard plugin does pose one problem...how to allow the user to specify the mode of operation setting for each servo.I know that I’m getting to this thread a bit late and you may have already made your decision, here’s a method that would let you keep the cheaper 16F688.

Setting the configuration would be easy without adding additional hardware or other external software. Assuming that there is no reason to change configuration on the fly, just use the channel output pins. For each output, externally temporarily jumper it high, low or leave open and turn the power on and off. When power is first applied, set as an output high and read for a low, set it low and read for a high. If the read matches the output, it’s open. Set these values in E2, then sit and do nothing. Resistors aren’t needed since each port is internally limited.

If you consider an open jumper as a disabled port and having all eight outputs being disabled as an invalid configuration then reading any pin as a high or low would signal configuration mode. If all eight are found open then just read the configuration from E2 and move on to run mode.

[g2ktcf]

I know that I’m getting to this thread a bit late and you may have already made your decision, here’s a method that would let you keep the cheaper 16F688.

Setting the configuration would be easy without adding additional hardware or other external software. Assuming that there is no reason to change configuration on the fly, just use the channel output pins. For each output, externally temporarily jumper it high, low or leave open and turn the power on and off. When power is first applied, set as an output high and read for a low, set it low and read for a high. If the read matches the output, it’s open. Set these values in E2, then sit and do nothing. Resistors aren’t needed since each port is internally limited.

If you consider an open jumper as a disabled port and having all eight outputs being disabled as an invalid configuration then reading any pin as a high or low would signal configuration mode. If all eight are found open then just read the configuration from E2 and move on to run mode.

Ernie,

I already have this in the schematic as it is what I have done in the past. The real question is how many different types of servos are out there? I got some info from Hitech


Thank you for choosing Hitec products. 98% of our servos are 1500uS at neutral. The pulse offsets are 600uS. 900uS to 2100uS is the pulse width.

I know Futabas are a bit weird as they have a neutral position of 1520 uS. I am inclined to ignore this for the moment.

Chris

[ErnieHorning]

I don’t know what the range can be either and frankly, I forgot about this so I’m proposing a different method. Why not just use Vixen. For a channel that you want to set, tie the output low. Now use the sequencer to program the selected channels.

For each channel:
Byte 1 – Mode (0 = Disabled, 1 = Standard, 2 = Extended.)
Byte 2 – Minimum pulse width (times 10)
Byte 3 - Maximum pulse width (times 10)
Byte 4 – Neutral position (times 10)
Byte 5 – Change rate (set the speed at which the servo moves)
Byte 6 – …

Store in E2.

You can use the pulse width values to ignore anything outside this range so the servo doesn’t get stuck a just draw excessive current or set the span so you can always use 0 to 100% in Vixen.

Pull the jumper(s) and you’re done.

[chilloutdocdoc]

I'm not sure how "right" I am in reading this. But I have an idea, granted I could, (and probably am) COMPLETELY WRONG!


1) If this byte is less than 128 (0x80), it is for some protocol that this firmware cannot handle (reserved for future use).
The command/address byte is retransmitted, as are all the remaining bytes in the packet.

Couldn't you set the PIC to read a command byte of something less than 128, which would just get sent through any current controllers (so I think).

If the PIC saw a command/address byte set for servo control. It would read the values for each channel, and then set the servo option based on that. Theoretically you could program up to 256 types of servos? Unsure as to how the PIC's internal memory and/or the firmware could be written.

However, this does add into account the fact that somehow you would have to transmit this lower byte, either by a plug-in, or scripted sequence (possible?) or separate (spelled it right Chris, just for you :P) to set the servo positions, and then the only difficult part would be converting 0-100% to your PWM values for the servo while sequencing (a small calc app would be useful (I could do that =).

Edit (4/20/09 1:50ish AM EST)

I don't mean to denounce any particular talked about methods, I'm just trying to think of a non jumper idea for those of us that are either too lazy, or have controllers that lie under snow for various amounts of time. I for one fall under the too lazy portion, while many of our members fall under the snow blankets.

[g2ktcf]

Gents,

This entire project is based on the RENARD comm protocal....ie. no changes within Vixen...


Ernie,

There is no need to pull the jumpers. I already have a 8 position DIP switch setup to handle the input parameters with a transistor "switch" killing power to these inputs.

However, it seems that you may be assuming that all 8 servos are the same. At this point, Don and I are NOT making this assumtion. In fact, I cannot bank of the fact that all servos can be run at 5.0V or 6.0 (most all seem to work at 4.3V).

What Don and I have not discussed is "grouping" like servos..for instance, all extented range servos must start at Position 8 and go down...then in the jumper input becomes the changeover value in binary. This is just a thought as we try to work through things.

Don is a bit busy right now with his group buy so I am just banging ideas around.

Would anyone be opposed to only using one brand of servos with each board????

Chris

[scorpia]

I'm not sure how "right" I am in reading this. But I have an idea, granted I could, (and probably am) COMPLETELY WRONG!



Couldn't you set the PIC to read a command byte of something less than 128, which would just get sent through any current controllers (so I think).

If the PIC saw a command/address byte set for servo control. It would read the values for each channel, and then set the servo option based on that. Theoretically you could program up to 256 types of servos? Unsure as to how the PIC's internal memory and/or the firmware could be written.

However, this does add into account the fact that somehow you would have to transmit this lower byte, either by a plug-in, or scripted sequence (possible?) or separate (spelled it right Chris, just for you :P) to set the servo positions, and then the only difficult part would be converting 0-100% to your PWM values for the servo while sequencing (a small calc app would be useful (I could do that =).

Edit (4/20/09 1:50ish AM EST)

I don't mean to denounce any particular talked about methods, I'm just trying to think of a non jumper idea for those of us that are either too lazy, or have controllers that lie under snow for various amounts of time. I for one fall under the too lazy portion, while many of our members fall under the snow blankets.

i have gotta say i allways thought this was how it should be done in an ideal world. but i think there would be some issues with things like the renards not sending data back to the pc. and also there would need to be pc side software written for this. but yes ideally this would be great and i think it was the original intention of the "128" character in the renard protocol.

but having said that the current scheme would work, just not as nice IMHO.

[chilloutdocdoc]

i have gotta say i allways thought this was how it should be done in an ideal world. but i think there would be some issues with things like the renards not sending data back to the pc. and also there would need to be pc side software written for this. but yes ideally this would be great and i think it was the original intention of the "128" character in the renard protocol.

but having said that the current scheme would work, just not as nice IMHO.

Not saying any design is nicer than any other, if it works, and it's repeatable, it's a far more than acceptable design. But as Chris said, and I neglected to remember at nearly 2am, the goal is for no changes to the Renard Comms.

And I would assume that most people stick to one brand of servo's, and if they don't they could probably just use the larger of the settings on the boards, and be sure to underrun the smaller servos, or risk burning them out. or just build 2 boards

[omzig]

In fact, I cannot bank of the fact that all servos can be run at 5.0V or 6.0 (most all seem to work at 4.3V).All of the RC servos that I've seen will operate at 5V. Most have an operating range somewhere between 4V and 6V. Sometimes they will list specs at something like 4.3V to show the minimum torque. At a higher voltage they will have higher torque and speed, up to the maximum voltage. Here is a Futaba chart (http://www.radiosouthrc.com/Futservochart.htm) that shows specs for their servos at 4.8V and 6V. I have a couple of servo controllers and they both operate at 5V and are not adjustable.

[chilloutdocdoc]

Most servo's I've seen (YMMV) are spec'd at Either 4.8V, 5V, 6V, or a combination of the listed. However, if you were to build the board and somebody were to use a lower power servo, couldn't you put a resistor inline to lower the voltage?

[ppohlman]

Hey Don,
Any updates on this project?

[omzig]

Sorry, but I've been very busy lately with some remodeling projects that are, as usual, taking way longer than expected. Our kitchen floor currently consists of temporary plywood laying across the floor joists. My wife won't let me work on any BF things until I finish her floor. I haven't forgotten about this, I just haven't had the time to finish it. I started to set it up on a breadboard but I was missing a couple of parts. I have all of the parts now, so it's just a matter of trying to find time.

[ppohlman]

Not a problem. I know exactly what you mean about finding the time. I currently have several projects that are in progress (lawn, sprinklers, deck, etc...). I hadn't seen anything on this thread and was just checking up on it.

Thanks for all that you have done so far.

[omzig]

Unfortunately I am going to have to scrap my plans for this project this year. I simply don't have the time to work on it. I now have another remodeling project that has to be completed quickly because it looks like my wife's uncle is going to be moving in with us for a while because of medical issues. I am going to expand the in-law suite that I built for my father-in-law last year to accomodate him. It's going to be hard to find time for any BF things.

If anyone would like to see the firmware that I wrote for this, let me know.

[djulien]

If anyone would like to see the firmware that I wrote for this, let me know.

Yes, I would like to take a peek.

don

[ppohlman]

I'm sorry to hear that this project is being postponed. I was really interested in the final product.

More importantly I hope that your wife's uncle is/will be doing better.

Are you planning on posting the firmware here or are you going to send it to people? I'd like to play with it when I get time too.

Thanks for all that you've done with this so far.

[ErnieHorning]

I was also watching this project. I’ve never played with servos before but they looked to be interesting. I know that a lot of people just buy the servos but it looks like they’re not too hard to build. Supposedly it’s not too hard to turn most motors into a servo. It seamed like a good use for wiper motors.

Think of a Christmas present or Jack-In-The-Box where the top opens and closes and you only need the motor. No switches to detect where to stop.

How about a Santa’s workshop present making machine where the parts actually move.

If you’re sending the code out, I’d like to be on that list. Not that I need something else to do, I don’t want to see this get lost either.

[omzig]

I'll post the firmware here. I need to figure out which version though. There were many different versions because I couldn't decide how to handle the changing of settings. I never did really make up my mind, but I was leaning toward using one of the 8 channels as a control channel.

I need to clean the code up a little and add a few more comments and then I'll post it.

[P. Short]

This topic seems to be on hold, but I had a thought...

With the newer Renard plugins I think that it is not necessary for a controller to use exactly eight channels worth of data in the stream. What the controller would need to do is simply remove the amount of data that it needs from the data stream, nothing more. It might be possible to do a similar trick with the data stream generated by the earlier Renard plugins (for Vixen 1.x), but it might be difficult to write the code that would work there (the controller would need to hold more state information than previously, essentially packet re-assembly). But the benefit of this is that a servo controller, for example, could use one channel for control/configuration information and the other channels for the servo position information.

Also, it would be a little more complicated explaining things to people writing sequences, since some of the old ways of thinking would be changed.

[g2ktcf]

This topic seems to be on hold, but I had a thought...

With the newer Renard plugins I think that it is not necessary for a controller to use exactly eight channels worth of data in the stream. What the controller would need to do is simply remove the amount of data that it needs from the data stream, nothing more. It might be possible to do a similar trick with the data stream generated by the earlier Renard plugins (for Vixen 1.x), but it might be difficult to write the code that would work there (the controller would need to hold more state information than previously, essentially packet re-assembly). But the benefit of this is that a servo controller, for example, could use one channel for control/configuration information and the other channels for the servo position information.

Also, it would be a little more complicated explaining things to people writing sequences, since some of the old ways of thinking would be changed.

Phil,

Don and I discussed this a way back. We both felt that it would be too confusing to the user to have to remember any special things while sequencing. The reason we were discussing it was being able to "intialize" the controller with some servo parameters.

Chris