Control loops over UART

[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.