Control loops over UART

[ZeroResistance]

I have a particular case where I have 2 modules each module has a mcu each. Now module one has sensors connected to it and module 2 has actuators connected. Now both these modules would connected by some interface like UART, CAN etc.
There would be some form of control loop for the actuators on module 2 based on the sensor readings on module 1. My questions are:
1. If I'm using the UART at high baud rate (> 1Mbps),  what would be the distance limitations between the 2 modules.
2. Is there any special cabling necessary for transmitting data at high rates, will twisted wire pair do? or is a shielded cable necessary?
3. What are the implications of running a control loop over this interface?

Even at 1 Mbps each byte would take around 10uS to transfer. But since this is not a dedicated UART for the control loop there might be additional overhead. I finally would like to update the output at least 500 times a sec.

[Buriedcode]

You could use RS422 between the two modules giving you >3Mbaud, and would use two twisted pair.  If half-duplex comms is ok, (or if traffic is mostly one way) RS485 might be better as it uses a single twisted pair.  For 1MBaud the limitation is ~100m. 10Mbaud ~10m.

The implications depends on how much data you're sending.  Of course, lots and lots of data from sensors takes time, which slows the loop down, and all depends on the application. Significant delays can cause oscillation in the control loop, but again this is all down to what are controlling and what sensors you're using.  It won't matter if its something like temperature control that is inherently a slow process.

Essentially you're doing the control loop on 'module 2', with 'module 1' being the extension for the sensors.  Providing that s all module 1 is doing, and module 2 services the incoming data quickly I don't see much more delay that using the sensors directly on module 2, except of course for comms delays.

What kind of system are we talking here?

[Hypernova]

What is the network cycle rate you are looking at? This is a product of the baud rate and packet length. Most control processes work fine beyond 100us loop time. A jelly bean SMPS controller works at the 10us loop range.

For example, at work I just tested some Tamagawa rotary encoders, they use RS485 at 2.5MBaud and about 11bytes for a full data (single+multi turn position, status bits etc) packet. This gets you about 60us of motion control loop time (and delay) and their driver seems to work fine with that limitation.

[rstofer]

If you are modeling the system in something like Matlab, add a Transport Delay to the feedback path.
If the delay is long compared to the response of the system, I can see this adding up to disaster.

[Phoenix]

Implications
- System delay can SIGNIFICANTLY reduce phase margin
- Need for error detection/error correction in the communications
- Safe behaviour if communication fails (need to keep operating during small fault or must stop straight away)

An update rate of 500Hz means 2ms period. If the data takes 10us this is barely any (0.5%) of the total cycle time, I would not expect it to be a problem. But you want to make sure the control loop uses a reading as close as possible in time to the new output. If the reading is old - this is delay.

Is it a request-response type arrangement? Is the sensor continuously sending data?

[ZeroResistance]

Thanks BuriedCode, Hypernova, rstofer and Phoenix.

As of now the traffic is mostly 1 way.
I see the suggestions are more toward RS422 / RS485 .. i guess this is due to robust nature of this interfaces over the RS232.
What if the distance between the 2 modules is max 1 meter would I still need to go RS422/RS485 for high baud rates or can I do RS232.
As regards the data I don't mind using 2 RS232 links one for the control loop and another for sending other sensor data if this would make the control loop.

To answer Phoenix:
Thanks for listing down the implications and also your comment about using the newest available data.
The sensor is continuously sending data, there is no request.
 

[Jeroen3]

I prefer CAN. It offloads fault recovery and retries to hardware. As well as defining some layer 2 stuff regarding frames and data formatting.
It is, I think, more suited for real time communications than RS-485 or RS-232. Which are more suited for configuration communications by a master or HMI.
CAN is technically similar to RS-485 in terms of differential pair.

In any case, with all named physical layers you will need a transceiver.

[AndyC_772]

Yes, though that's the raw bit rate. There's overhead with device IDs, bit stuffing and CRC data, so you won't get 1Mbps actual throughput.

[ZeroResistance]

Yes, though that's the raw bit rate. There's overhead with device IDs, bit stuffing and CRC data, so you won't get 1Mbps actual throughput.

Thanks for the info, of whatever little I know of CAN its based on frames right? and each frame can have max of 128bits and user can stuff in upto 8 bytes of data per frame.
Are there any licensing issues when using CAN or is it free to use?

[Jeroen3]

CAN will only cost you money if you buy a standard higher level proprietary protocol like j1939. Of if you need to buy the ISO standard that comes with it, which you do not.

There is also the optional one time purchase of a CAN to USB interface, for debugging.

1000 messages per second is about 15% bus load at 500 kbit, this gets you a theoretical 100 meters of cable.
And you are correct, it is based on 8 byte frames. See here: https://www.kvaser.com/can-protocol-tutorial/

[AndyC_772]

Yes, a CAN frame has an address (ID) and a data payload, which can be up to 8 bytes long.

CAN works very well for sensor devices. At regular intervals, a CAN sensor can simply transmit the value of its measured quantity onto the bus, and any other device which is interested can receive it. From a software point of view, there's no need to establish a two way dialogue between the devices; your sensor can simply 'shout' at regular intervals onto the bus, and any other device on the bus can listen or ignore it.

The nice thing about CAN is that error detection, retransmission and acknowledgement are all taken care of for you in hardware. Typically, once the controller is set up (which can, admittedly, be a bit overwhelming at first because there's a number of terms and parameters which may be unfamiliar), all you do is write the contents of the frame into hardware registers, then leave the controller to get on with it.

The controller:

- provides a hardware queue, so your code doesn't have to wait until transmission is complete
- calculates the CRC for transmission (and checks it on reception)
- waits until the bus is free
- transmits the packet
- handles arbitration, collision detection and retries
- optionally, generates an interrupt to let you know when transmission is successful

The receiver typically includes hardware filtering on device ID, so you can program up the list of IDs you're interested in, and only those will be received.

Physically, you need a microcontroller with a CAN interface, and an external transceiver. The connection between the two can be as simple as two wires, Tx and Rx. CAN transceivers handle the conversion between single ended and differential, and are remarkably robust against electrical damage.

[Howardlong]

I'll just mention that CAN has a very significant learning curve compared to RS232 etc UART style comms. I'm mentioning this because you may well find yourself spending more time getting up to speed with CAN than working on the rest of your project.

Particularly as your project is point to point, personally I'd stick with UART technology. But that's just my opinion* ;-)

* This is from my own experience of working on my first CAN project some years ago, but was a large project with several teams, and defining and aligning how CAN was used, together with having to implement a specific stack on several different module platforms, was not fun. In part, the choice of CAN turned it into a massively over engineered monstrosity. That was on a scheduled year long project, about ten years ago, and the project is still not finished, but I left the project some time ago as I couldn't see it realistically completing.

[JPortici]

learning CAN all by yourself (sigh) is much harder, especially if the controller is ridiculously complex (manufacturer dependent) I also think that UART over rs485 would be a good choice, add a byte or two for start of frame and checksum, the targed sends an "ok" or "wrong, tx again" frame byte and you're almost done.

then, depending on mcu you may have buffers and/or dma on the UART so you can mostly forget about putting/getting data

[Jeroen3]

How much data are you looking at transmitting? Do you plan to expand the system later on? Do you want to add a monitoring HMI?

[GeorgeOfTheJungle]

I finally would like to update the output at least 500 times a sec.

1s/500= 2ms, even @115200 baud you can send 23 bytes AND simultaneously receive another 23 in 2ms (full duplex). Use any differential line drivers/receivers for added noise immunity if you want and you're sorted.

[ZeroResistance]

How much data are you looking at transmitting? Do you plan to expand the system later on? Do you want to add a monitoring HMI?

Not more that 16 bytes currently.

[GeorgeOfTheJungle]

Easy-peasy differential driver and receiver:

[Hypernova]

Just broadcast those 16 bytes on a fixed schedule on RS422 and add some CRC8. If the receiver sees a corrupted packet wait for the next try and reuse the previous values. As long as miss rates are rare you probably won't notice.

[GeorgeOfTheJungle]

Not more that 16 bytes currently.

Is it text or binary data?

[AndyC_772]

Just broadcast those 16 bytes on a fixed schedule on RS422 and add some CRC8. If the receiver sees a corrupted packet wait for the next try and reuse the previous values. As long as miss rates are rare you probably won't notice.

As do that, you may as well use CAN. The CAN controller adds, and checks, the CRC for you. If there's an error, it doesn't acknowledge the packet, and the transmitter automatically re-sends it straight away without any software intervention necessary.

[GeorgeOfTheJungle]

You don't need CAN to send 16 bytes from A to B, come on!

[ZeroResistance]

Not more that 16 bytes currently.

Is it text or binary data?

binary

[ZeroResistance]

Just broadcast those 16 bytes on a fixed schedule on RS422 and add some CRC8. If the receiver sees a corrupted packet wait for the next try and reuse the previous values. As long as miss rates are rare you probably won't notice.

Do you think RS422 / RS485 is needed for 1 meter distances @ 1Mbps ? Would RS232 suffice at these cable lengths?

[tszaboo]

Just broadcast those 16 bytes on a fixed schedule on RS422 and add some CRC8. If the receiver sees a corrupted packet wait for the next try and reuse the previous values. As long as miss rates are rare you probably won't notice.

As do that, you may as well use CAN. The CAN controller adds, and checks, the CRC for you. If there's an error, it doesn't acknowledge the packet, and the transmitter automatically re-sends it straight away without any software intervention necessary.

CAN is terrible choice for such a system. It is a point to point communication, RS422/485 is just faster, and a lot easier to work with.
OP: Just place an RJ45 connector on both ends, and you got 4 twisted pair signals with pre-made cabling for it. You could use any differential physical layer to route Tx/Rx and CTS /RTS if you like. Or select two pairs to run power.
Depending on the system, maybe Rx signal is not even required. If the message is wrong (CRC) just keep previous setpoint, dont do anything. If you have anyway the time to re-transmit your setpoint, then do it anyway, no matter if there is a new measurement point or not.

Easy-peasy differential driver and receiver:

Made by Maxim . I dont even have to justify it.

[GeorgeOfTheJungle]

In general moar speed => moar risk of data corruption. For 1m you don't need rs422 unless there's lots of (as in very very much) noise (unlikely) or floating or defective grounds/grounding (somewhat more likely). OTOH a max348 costs ~ nothing. BTW binary data is a pain in the ass, it takes ns to convert it to text and that makes comms easier (and human readable!).

[GeorgeOfTheJungle]

Made by Maxim . I dont even have to justify it.

LOL, what's wrong with them?

[tszaboo]

Made by Maxim . I dont even have to justify it.

LOL, what's wrong with them?

That it is Maxim. Search it, Maxim hate is a real thing.

[GeorgeOfTheJungle]

IDK, I've used their 422 drivers for a project to interface with Mac serial ports back in 199x and everything went fine, not a single problem.

[BrianHG]

If the message is wrong (CRC) just keep previous setpoint, dont do anything. If you have anyway the time to re-transmit your setpoint, then do it anyway, no matter if there is a new measurement point or not.

If CRC and re-transmit is too complicated, do it the 'dumb BrianHG' method, triple transmit every packet and only accept at least a 2 matches as valid data.  If you are getting more than the occasional single bit error here and there, which wont even be seen or affect performance in such a simple triple redundant system, you may want to re-think your com interface.  This system will also function with a unidirectional com interface and still get valid data through.

[AndyC_772]

CAN is terrible choice for such a system.

How so?

If your chosen microcontroller has support for it, or you can use a close variant which does, why would you not use it?

A CAN transceiver is simple and cheap, needs only a two wire connection, and the controller completely handles error detection and retransmission for you in hardware.

The only argument against its suitability that I'm seeing here, is that it's unfamiliar - but it really doesn't take long to learn.

(Disclaimer: last time I did a system anything like this, I used RS485 @ 6 Mbps)

[Howardlong]

CAN is terrible choice for such a system.

How so?

If your chosen microcontroller has support for it, or you can use a close variant which does, why would you not use it?

A CAN transceiver is simple and cheap, needs only a two wire connection, and the controller completely handles error detection and retransmission for you in hardware.

The only argument against its suitability that I'm seeing here, is that it's unfamiliar - but it really doesn't take long to learn.

(Disclaimer: last time I did a system anything like this, I used RS485 @ 6 Mbps)

Two words: Over engineered.

[Jeroen3]

No, overengineering would be to use Ethernet.

[Howardlong]

No, overengineering would be to use Ethernet.

That would have taken more than two words to explain though!

[jbb]

Hi ZeroResistance

Sorry for the long post; I didn't intend to write a textbook...

There are two big safety questions that you need to determine:

• Will a brief 'glitch' in the output actuators cause mayhem?  Some systems won't care (e.g. theatrical lighting dimmer packs controlling a tungsten light). Other system (e.g. multi-megawatt semiconductor) will die if fed an unlucky glitch.  This determines how much CRC etc. effort you need to go to.
• What happens if you lose the link? Will it be safe for the actuator to stop moving and wait?  You need to think about this early.

I've worked on great big beasts with serial comms inside (including one which used EtherCAT, which is truly good but has a lot of engineering in it ).  I suggest you take the trouble to make a solid link now, because link troubles will make debugging really hard.

What I can tell you about the overall scheme is this:

• There will be occasional multiple-bit errors in your transmissions.  Simple parity is not good enough to stop them.  I thoroughly recommend a CRC.
• Sometimes you will get heavy interference and lose many frames in a row.
• Sometimes the wires will break/fall off/be unplugged
• You need to make sure your sampling is good:
  • The sampling rate must be strictly regular.  Jitter (i.e. sampling instants jumping around) can lead to frequency aliasing and degradation of phase margin.
  • The control output update instant must be a consistent delay from the sample instant.  Otherwise you get degradation of phase margin.
  • Many designs delay the control update to exactly 1 cycle after the sample rate, but it's not necessary.
  • It's good to have a timed trigger to perform the control update at a specified moment (e.g. use a timer interrupt to trigger a DAC update)
• Leave some gap between the end of your processing and the control update deadline, 'cause you're always going to want just one more feature.
• At some point you'll want to add more data to the transfer (e.g. temperature measurements).  This might make your data frame unacceptably large.  You might want to think about how to get small amounts of high priority data through on schedule while also getting low priority through in the gaps.
• Abstract out (i.e. separate) your comms routines from your control code so that you can debug them separately.

On RS232 vs other:

• Getting RS232 to function at 1Mbaud is actually asking a lot.  Most transceivers don't go higher than 256kbaud so you'll have to select one specially.
• Getting differential pairs to do 1Mbaud is standard and should be no trouble.
• Differential pairs will have much less trouble with interference.  They generate less interference and are less sensitive to interference from other things.
• The above goes double if you need to get ElectroMagnetic Compatibility (EMC) testing done, e.g. FCC Part 15, EN55022 etc.
• The cost difference is really small.

In principle, you only need 4 wires for RS422 or 2 wires for RS485/CAN because the electronics works on the difference in voltage at the far end.  In practice, I suggest you do put a ground wire in because the electronics only tolerate so much 'common mode' voltage. Worked example:

• 2V differential Vdiff on 5V common mode Vcm.  V1 = Vdiff / 2 + Vcm = 2/2+5 = 6V.  V2 = -Vdiff/2 + Vcm = 4V.  No problem for many industrial spec chips.
• 2V differential Vdiff on 100V common mode Vcm.  V1 = 2/2+100 = 101V.  V2 = -2/2 + 100 = 99V.  Could well blow up industrial spec chips.

On protocols:

• It's easiest to strictly define the fast comms frame format.  Trying to do variable-width data and low latency is a headache.  Do not succumb to the temptation to e.g. stream JSON around. That's for software engineers whose toys don't spontaneously catch on fire if deadlines are missed.
• CAN data frames let you use all 256 values in a byte.  If you want that on an RSxxx link you'll need to work it into your low level protocol (many options available e.g. frame formats with length info or some kind of base64)
• If time is critical, don't convert to ASCII.  Send raw binary.
• Remember to define the endianness of multi-byte data (e.g. int16) in the link.  You can of course define it to match your processor choice.
• Be aware that C doesn't define: endianness; bit order of bitfields (could be lowest to highest or highest to lowest); and if padding is added to data structures (e.g. compilers for 32b machines may align int32 values to 4B boundaries and stuff padding bytes in without telling you!).  This is for efficiency reasons but can lead to serious traps.  You should make sure your real frame format matches your defined frame format.

Good luck!

[NorthGuy]

If you run the control loop at the first MCU (which has sensors), I guess it would be less data to transmit to actuators (as opposed to the data received from the sensors). You may even be able to eliminate the second MCU completely, only leave wires to actuators.

[CM800]

Hi ZeroResistance

Sorry for the long post; I didn't intend to write a textbook...

There are two big safety questions that you need to determine:
-SNIP-

On RS232 vs other:

• Getting RS232 to function at 1Mbaud is actually asking a lot.  Most transceivers don't go higher than 256kbaud so you'll have to select one specially.
• Getting differential pairs to do 1Mbaud is standard and should be no trouble.
• Differential pairs will have much less trouble with interference.  They generate less interference and are less sensitive to interference from other things.
• The above goes double if you need to get ElectroMagnetic Compatibility (EMC) testing done, e.g. FCC Part 15, EN55022 etc.
• The cost difference is really small.

-SNIP-

Good luck!

+1 on all of that.

I'd go with CAN, you can always implement CANOpen ontop of that, but I gotta agree it's no 'easy' feat.

HOWERVER:


If you plan to do any other projects with comms, the code & knowledge can be re-used and it will be well worthwhile

[tszaboo]

CAN is terrible choice for such a system.

How so?

If your chosen microcontroller has support for it, or you can use a close variant which does, why would you not use it?

A CAN transceiver is simple and cheap, needs only a two wire connection, and the controller completely handles error detection and retransmission for you in hardware.

The only argument against its suitability that I'm seeing here, is that it's unfamiliar - but it really doesn't take long to learn.

(Disclaimer: last time I did a system anything like this, I used RS485 @ 6 Mbps)

I've used CAN system for years, I've used RS485 systems for years, I prefer RS485. It is more flexible, higher speed, requires less software and datasheet reading to make it work. Something like RS422 is pretty much the ideal for a control system, alternatively it can be some LVDS or something in between.
CAN is a good choice if you have data sockets, endpoints, multiple master, and you can build really complex systems with it, with less effort than it would take to make the same system from RS485. I agree. But this is a simple system, point to point.
Unless you are working for a company with lots of CAN stuff, knowledge tools, etc... The simplest solution is the best. RS485 is easier to debug, easier to build. For example, most scopes, CAN decoding cost 500EUR. If you need a CAN usb converter, that is an additional 500. RS485/422 is literally 10 EUR, and it works with the usual debugging software. CAN is also seriously limited in speed by modern standards.

[GeorgeOfTheJungle]

CRC or not, use text instead of binary data, it makes the protocol much easier. Choose a character to signal start of frame (say '#' for example) followed by n hex chars and that's it: #0ff89232. The program to sync to frames such as that is "two lines" and converting from hex to binary takes ns, and on top of that that stream is human readable.

With binary data the character you choose to mark the start of frame can appear as data too and that complicates the protocol unnecessarily.

[Jeroen3]

CRC or not, use text instead of binary data, it makes the protocol much easier. Choose a character to signal start of frame (say '#' for example) followed by n hex chars and that's it: #0ff89232

Please take a look at standardized ASCII 0 to 31. If you were not aware of the American Standard Code for Information Interchange, you are now.

[GeorgeOfTheJungle]

I prefer to use printable chars if I can, thank you very much 

[ZeroResistance]

Thanks everyone... for the thought provoking answers..
Special thanks to Jbb, those were some awesome suggestions...

seems like RS422/RS485 is the way to go in the present scenario..

Does RS422 / RS485 make sense if I reduce the distance between the 2 units and bring it down to a couple of feet.

NorthGuy gave a good suggestion of executing the whole control loop on the first MCU itself (where all the sensors are attached) this seems to be a good idea, I'm looking into this too, just keeping my options open at the moment..
i guess with this method only actuator commands will have to be sent over the link that would greatly reduce the burden on the link..

[BrianHG]

If your first MCU is only used for decoding & filtering the sensor, and you want to save on a balanced RS485 transceiver, in the past, I used a 65cent 8 pin pic, internal clock, only 5v, used the PIC's comparator inputs as a true differential RS485 receiver, and swapped the same 2 comparator analog inputs to output to transmit a balanced differential RS485 output.  However, you need to use a software UART since the comparator's output cannot be read by the HW internal UART and when outputting, you need to swap 2 IOs simultaneously.  But with 32Mhz, reading a mechanical motion sensor & if you have some good skills with PIC programming as to create an old fashioned software UART interface, it is a single 8 or 14 pin IC solution which will only need line series and termination resistors for the RS485.

[ZeroResistance]

in the past, I used a 65cent 8 pin pic, internal clock, only 5v, used the PIC's comparator inputs as a true differential RS485 receiver, and swapped the same 2 comparator analog inputs to output to transmit a balanced differential RS485 output

that's pretty nifty ... however does the comparator has sufficient drive to feed into the terminator resistance. And you would need 4 comparators right? 2for the transmission and another 2 for the reception?

[GeorgeOfTheJungle]

Can do it 100% in software

[ebclr]

Did you evaluate the possibility of the simple reliable and old analog 4..20 ma current loop system?

[mikerj]

CRC or not, use text instead of binary data, it makes the protocol much easier.

It may make it easier to debug with a serial terminal, and to demarcate the start/end of a frame but text makes everything else more difficult and slower to execute.

[GeorgeOfTheJungle]

Yes, ns slower. Hex to bin and back is fast.

[Jeroen3]

It would be unnecessarily slow to do m2m in decimals.
Yes, talking to you, web guys.

[BrianHG]

in the past, I used a 65cent 8 pin pic, internal clock, only 5v, used the PIC's comparator inputs as a true differential RS485 receiver, and swapped the same 2 comparator analog inputs to output to transmit a balanced differential RS485 output

that's pretty nifty ... however does the comparator has sufficient drive to feed into the terminator resistance. And you would need 4 comparators right? 2for the transmission and another 2 for the reception?

You only need a comparator in reception mode, to transmit RS485, you can just use 2 digital outputs, A RS485 output signal are just 2 digital outputs with 1 with an inverted value of the other.  Also, the same 2 balanced wires work in both directions.  I know looking at the block diagram of an RS485 transceiver shows this as 2 comparators, and a single cable half-duplex bidirectional unit has the output comparator with an output enable, with it's outputs shorted to the inputs of the receiver.  This is the same as in the PIC's software when transmitting you would switch the 2 comparator inputs into digital outputs & drive a +&- version of the serial data on those same 2 pins.  If you wanted full duplex RS485, you would keep the comparator input always as inputs and just use 2 additional outputs, always outputing, the +&- USART data.

As for my recommendation, the idea was to simplify one side, just the sensor reader & decoder to generate the digital loop data.  The other side would have had a full RS-485 transceiver IC with large MCU using a normal USART.  You can always do this MCU internal comparator trick on both sides, but, remember the UART will now be software on both sides & this might not be what you want for your main processor.

Now, with only 1-2meter distance requirement, I personally might even test just test using a terminated TTL signal in a cheap coax cable.  The coax would also virtually eliminate emi leaking out during EMC FCC testing.  This will allow you to use the built in hardware UART in both MCUs and with Microchip's PIC's +/-50ma drive per IO when operating at 5v, (most of the new PICs), you should be able to drive a terminated cheap coax error free at a megabaud.  I would use 1 coax, 1 direction with triple redundant data transmit scheme.

For larger distances, or unshielded twisted pair wiring like network cable, you will have no choice but to use the RS485 method of your choosing to prevent errors.

[GeorgeOfTheJungle]

It would be unnecessarily slow to do m2m in decimals.
Yes, talking to you, web guys.

Decimal? Who said decimal? Just convert the bytes to hex text and that's it, easy peasy, it takes "ns" per byte.

[Jeroen3]

Yes, that's what I meant. Two lookup tables and you're done. ROM space is dirt cheap.