Comms latency - RS232,RS422,RS485 etc etc

[PA-Paul]

Hi All,

One of the projects I'm working on is a multiaxis positioning system (typically 3 or 4 axes of stepper motors). At present we're using one Parker ViX stepper drive/controller per axis. One of the drives is connected to the PC via an RS232 (with a usb-rs232 adapter in line) and the other drives then daisy chain off that.

For our application, we basically do point to point positioning, with some data acquisition in between (step and measure essentially). All movement is controlled on a PC with software written in labview (so we send move commands etc over the RS232 interface from VISA within LabVIEW). We're currently looking at possibly changing the motor controllers and one of the motivations is the latency we see when sending commands to the drives over the RS232 interface (currently configured to the ViX max data rate of 19200). Setting up a move and issuing the move command currently takes us about 100-150 ms... which is either a lot or not much depending on how you look at it! But I'd like to reduce it if at all possible!

There are various other stepper controllers out there which all work on different comms interfaces, but no one seems to specify the communication latency of the various interfaces. Can anyone give me a rough idea of the relative expected performance of the following interfaces:

RS232, RS485, RS422, Ethernet, USB (a direct USB rather than one of the others with a USB converter).

I realise it may well depend on implementation as well, but any sort of rough idea would be better than what I have right now!

Thanks!

Paul

[ned]

In general, Ethernet and USB will be much faster than a serial protocol. At the same baud rate, 232, 422, and 485 are all comparable (probably identical, in fact, since the major difference between them is voltage levels and the number of devices that can be connected). The protocol and implementation running on top of the communication is equally important. For example, the Parker 6k motor controllers support both serial and ethernet communication. Over ethernet, they support two different protocols. One is text-based and works just like the serial connection. The other is a binary packet containing variable values. The manual for the 6k COM server notes, "Although variables can be sent as a command using the Write method, the time taken to parse the command and check data validity is longer than the time to send an entire variable packet."

[jzoller]

Can anyone give me a rough idea of the relative expected performance of the following interfaces:

RS232, RS485, RS422, Ethernet, USB (a direct USB rather than one of the others with a USB converter).

NI's put together a nice set of charts on it:

http://zone.ni.com/devzone/cda/tut/p/id/7278

Joe Z.

[jdunham]

For Serial at 9600 baud, you can transmit roughly one character per millisecond, so often a motion control system will be activated by commands of 5-10 characters in length. 9600 baud is very common, but when speed matters, it's also common to run serial 115kbaud, about 12x faster. Some modern faster UARTs (serial chips) go up to 921kbaud, but that's not so common.

The serial connection has a UART chip at each end, but I don't think they will add anything noticeable to the latency. Many motion control system have a pretty slow processor as their controller so the gating factor is often the time it takes that processor to interpret and act on the position update message you are sending. So, often the link latency has very little effect on the control latency.

[PA-Paul]

Hi Guys,

Thanks for the replies.

So it looks like if I move to a controller with an "RSXXX" the only way I'll be able to improve latency is to find something running at a higher baud rate (the parker ViX controllers are limited to 19.2 kBaud). Otherwise, I may be better off running something with ethernet communications or a direct USB...

Thanks again

[COsiecki]

I have a similar project, and I wanted to have it run faster as well. I don't know if it will work for your system, but the system we have lets you create movement programs that you can run without having to send individual commands. To deal with the timing issue, I just run the data acquisition continuously and watch for "flat" spots in my data, since that corresponds to where the motor pauses between moves. I can put very small delays in between my moves and pull that out of the data. It still takes a while to copy the programs to the controller, but once its sent, I can rerun it as many times as I want. This may help speed things up.

If your particular task doesn't have data that would easily let you determine where the motor stopped, you could use the status bytes from the motor controllers to read when they change state from moving to stopped. If you aren't having to send individual commands, polling status should be fairly quick. Some controllers even have digital outputs that indicate when the motor is moving. You could use this as a trigger for your acquisition.