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!).