Migrating RS-232 to RS-485 (or something similar?)

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

The company I work for design and manufacture industrial machinery. The current control system used on said machinery works via a main control board, with separate modules as and when needed depending on the extra options that particular machine requires. Currently I'm in the initial design concept stages of updating this control system as it's approaching 10 years old, so a few of the devices have gone obsolete, and in truth I think the system's a bit over stretched as the machine(s) that it controls have been further developed.

I'd like your opinions on a proposal to improve the communication within the system. At the moment I don't have any baud rates as speed isn't really what I'm concerned with right now, I'm more interested in how messages get from the host PC running the UI application, to each device in the system. The chain so to speak.

So as it stands the system works a little like this...

 

 

CommsSlave 1Slave 2 and Slave 3 are all ATmega1280s, and these 4 micros are on the main control board. As I understand it when this system was first designed, though there was the capability to communicate with external modules, there was no need for it at the time and no modules to communicate with. 

So originally the comms chain as you can see from the above image was PC ---> Comms ---> Slave.

Fast forward to 2017 and this system not only has modules for all three slaves, but those modules have slave modules too...

Now while this works, there are flaws which I'm sure jump out to you straight away. For me the 2 main things are that any messages to modules 4, 5 & 6 have to go through everything else before it since RS-232 is point-to-point (as is UART within the main control board). and on top of that, should Module 1 stop working, then consequently so will module 4 (In truth this is the case for the first 3 slaves on the main board too).

Now initially the 3 slaves on the main board were there because the initial designer couldn't get all of the needed functionality out of 1 device (there are other reasons too related to how the system is set up which I'm not getting into now). What I'm going to do first of all is get rid of the first chain of UARTs from comms to the slaves, and have just 1 microcontroller on the main control board (an XMega to be exact). From here the main board will communicate to external modules via RS-485 like so...

The advantage this has is that the chain that the transmissions has to go through to get to it's intended target is pretty much always the same, and also that it doesn't matter if a slave goes down or is removed, it won't affect the rest of the system.

 

Here's the snag: With the old system, if the last module in the chain had a message to send back to the PC, it could do so at pretty much any time (once any prior transmissions from that module had finished of course). As I understand it, and please correct me if I'm wrong by all means, with RS-485 only the master can initiate transmissions. What I was thinking to get around this was to have an extra signal shared between master and all slaves. It would be Hi-Z in normal conditions (pulled high at some point, most likely master end), and then should a module have something to send back, it would pull this line low. At that point the master can poll all the slaves to see which one it is, once it finds it carry on and get the data to send back to the PC.

What are people's thoughts on this? Does it seem like a good approach? Can anyone thing of a better alternative? All feedback and suggestions welcome.

 

PS this project is in the very early stages of development, so by all means point out anything you think I might have not accounted for that you feel I should have, but please appreciate that I'm merely playing with ideas at this stage! :) 

 

Edit: typos

Last Edited: Fri. Jan 27, 2017 - 12:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you have some thing existing that works, I have to ask:

 

 

what is the baud rate today and packet size

what is max delay you can live with

how many Slave X do you expect to need.(max for the hole system).

is this "true" rs232 or are there some other drivers in the system

is electrical noise a problem  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Left field: have you thought about some kind of network topology? Ethernet perhaps? CSMA/CD handles two(+) devices on the wire trying to send at the same time.

 

For a real 2017 solution ("IoT") I guess you'd actually have them all connecting with radio links - but not often a great match for an industrial environment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem with your extra line is that you can get race conditions where two slaves both want to talk at the same time. Why not simply have the master poll the slaves in turn.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Certainly there are protocols or methods to signal a transfer "back" from an RS485 slave.  But let's consider whether you really want to...

 

Backing up, I'll +1 looking at RS485 or similar.  You get better distance and noise immunity and multi-drop capability.

 

Now on to your queries -- I have a number of industrial apps with "important" modules on multi-drop RS485.  ("Important" means causing a pump to run, or relay to energize, or similar.)  I have no "back channel" comms even for the "important" signals. How can I get away with that?  Average poll-response sequence per module is 3ms.  So with e.g. 10 modules I get the "important" piece of info within 30ms or so.  Now, you have to lay out the numbers and determine whether that is fast enough.  Is it fast enough for an end-limit on a machine tool?  perhaps not.  Is it fast enough for solenoid-activated chemical pumps, or high-speed industrial doors?  Yes.

 

Side note:  My slaves typically have a watchdog timeout of 65ms, and only WDR when a poll received.  After reset the "important" I/O is put into a safe state.

 

Remember that "master" is a concept -- electrically the nodes are the same whether master or slave.  The nominal master could pause between each poll leaving a slot for a slave to send an alert message.  Or an empty slot at the end of a round of polls.

 

But now consider that leaving these empty slots slows down the normal polling -- in the end are you just as well off with continual polling as fast as practical with no delays?  That's what I decided.

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Since you have some thing existing that works, I have to ask:

 

 

  1. what is the baud rate today and packet size
  2. what is max delay you can live with
  3. how many Slave X do you expect to need.(max for the hole system).
  4. is this "true" rs232 or are there some other drivers in the system
  5. is electrical noise a problem  

 

  1. As I said I don't know what the baud rate(s) being used are, however I know it's between 19k2bps and 56kbps.
  2. Assuming you mean the time it takes for the message to get from the PC to the target module, max delay is hard to say at this point. The majority of what is required from the system is motion control. And every module will of course feature it's own microcontroller which I'll be programming, so for operations that are particularly time critical I can give more responsibility to the firmware of that slave/ module. But generally speaking, the faster the better, obviously.
  3. At the moment, the most we could possibly require is 9, however I know there is already a project in the pipeline where there will be 24+.
  4. I'm not 100% sure what you're asking here, but communications between the control board and the modules, and module to module, is essentially UART converted to RS-232 via converter ICs, then back to UART once it gets to the destination
  5. Yes, the system operates in an industrial environment so absolutely.

 

 

clawson wrote:

Left field: have you thought about some kind of network topology? Ethernet perhaps? CSMA/CD handles two(+) devices on the wire trying to send at the same time.

 

For a real 2017 solution ("IoT") I guess you'd actually have them all connecting with radio links - but not often a great match for an industrial environment.

 

Ethernet did cross my mind yes, but I wasn't sure how suitable it would be in a harsh environment. I'll read up on it though seeing that you suggested it!

I did think about somehow integrating IoT into the system but as you said, not great for industrial environments, and in truth there isn't any real need for wireless comms. You could argue that it would eliminate the need for drag-chains and such but the systems being communicated with still need power so those drag-chains would still be required. Might as well utilize them and put comms cables in them!

 

 

Brian Fairchild wrote:
The problem with your extra line is that you can get race conditions where two slaves both want to talk at the same time. Why not simply have the master poll the slaves in turn.

 

To get around the issue of multiple slaves wants to communicate, I thought what I could do was that should the master notice this line go low, poll every connected slave in turn, from lowest to highest until one of them says 'yeah that was me' then the master can continue to listen to that slave as normal. Now lets says this slave has address 10 assigned to it in this case. Whilst this slave is being dealt with by the master, another slave who also pulled the signal low, lets say address 14, continues to keep the line low. Once the master and the slave at address 10 have finished, that slave releases the signal and goes back to Hi-Z, and at the same time the master, noticing the line is still low, starts polling again, only rather than starting from the lowest, it starts from the next address.

If you or anyone can see any flaw(s) or possible problems with that solution then by all means, point them out to me.

Continually polling did cross my mind, however I thought the extra signal might help me make things more efficient and save me constantly polling. 

 

 

theusch wrote:

Certainly there are protocols or methods to signal a transfer "back" from an RS485 slave.  But let's consider whether you really want to...

 

I wasn't aware this was possible, thanks for pointing it out, I'll look it up!

 

theusch wrote:

Backing up, I'll +1 looking at RS485 or similar.  You get better distance and noise immunity and multi-drop capability.

 

Now on to your queries -- I have a number of industrial apps with "important" modules on multi-drop RS485.  ("Important" means causing a pump to run, or relay to energize, or similar.)  I have no "back channel" comms even for the "important" signals. How can I get away with that?  Average poll-response sequence per module is 3ms.  So with e.g. 10 modules I get the "important" piece of info within 30ms or so.  Now, you have to lay out the numbers and determine whether that is fast enough.  Is it fast enough for an end-limit on a machine tool?  perhaps not.  Is it fast enough for solenoid-activated chemical pumps, or high-speed industrial doors?  Yes.

 

That's a good point, I suppose really I need to factor in worst case scenario and calculate what the average poll-response time is in my case and decide if it's acceptable...

 

theusch wrote:

Remember that "master" is a concept -- electrically the nodes are the same whether master or slave.  The nominal master could pause between each poll leaving a slot for a slave to send an alert message.  Or an empty slot at the end of a round of polls.

 

That's a nice idea, though I'm not sure what would happen if more than 1 slave sent a message at the same time? 

 

 

PS: Something I forgot to mention in my OP was whether I meant full-duplex or half-duplex RS-485 - at the moment I'm thinking full-duplex, unless anyone is aware of any draw-backs of full-duplex RS-485 that half-duplex caters for?

 

Thanks for all the feedback and suggestions so far!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could make a network where all units that needs to send data are masters. This can be done by using a time-slot system. If you read the specifications of the P-net (www.process-data.com) you could get some inspiration. In the company I work we have used the P-net since 1986 and though it is an old standard does not mean it also can be used today. It is simple.

We have around 40.000 units running RS485/P-Net around the world.  The biggest installation is with 215 units on 14 nets.

We use only 9600 baud since the bus is intrincically safe, the standard P-Net is 76200 baud.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
As I understand it, and please correct me if I'm wrong by all means, with RS-485 only the master can initiate transmissions.
RS485 is a physical spec.

Modbus on RS485 is a data spec that's master and slaves.

Modbus RTU Protocol Overview

http://www.rtaautomation.com/technologies/modbus-rtu/

Alternatively, collision sense multiple access could work on RS485.

Howard_Smith wrote:
Can anyone thing of a better alternative?
Modbus on RS485

Further alternatives :

  • M-LVDS
  • USB
  • Ethernet

 

M-LVDS does not have the range of RS485 but it's less power consumed versus RS485.

 

USB is common for MCU.

There's industrial use of USB but its bus length is much less than RS485 with multiple hubs to obtain range.

There are industrial USB bridges and gateways to overcome the lack of range.

Have seen vehtronic use of USB (medium truck; somewhat common for light trucks and cars)

XMEGA doesn't have a USB HCI (iow XMEGA are USB devices instead of hosts); there are several ways to add USB HCI.

USB is deterministic for some of its data; USB interrupt transfers and isochronous transfers are periodic.

 

Ethernet is common for industrial and automotive use and has good range.

Have dealt with Ethernet for vehtronics and it works well.

An Ethernet network would have to be hardened for automotive (lightning) and industrial automation (EFT from motors, generators, arc welders, etc); such is reasonable to obtain.

Ethernet is not deterministic but it can be enhanced for that.

 


FreeMODBUS - A free MODBUS ASCII/RTU and TCP implementation

Ports ASCII/RTU

AVR

http://www.freemodbus.org/index.php?idx=32

https://www.avrfreaks.net/forum/modbus-xmega-0 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You might consider using CANbus, since it is multimaster any module can talk to any other module, and is multi-drop similar to 485. 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:

  1. As I said I don't know what the baud rate(s) being used are, however I know it's between 19k2bps and 56kbps.
If less than 20m per segment then might consider IO-Link (max 230kbps)

IO-Link

IO-Link

Technology

What is IO-Link?

http://io-link.com/en/Technology/what_is_IO-Link.php?thisID=76

IO-Link transceivers can be connected to MCU (single channel or multiple channel)

Howard_Smith wrote:
Ethernet did cross my mind yes, but I wasn't sure how suitable it would be in a harsh environment.
Works well for automotive and industrial if shielded (shielded twisted pair or STP)

An alternative for STP is PROFIBUS (Process Field Bus) (shielded RS485)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Left field: ...
More left field :

Assumptions :

  • All 'Slave x' are AVR MCU with UART MPCM (Multiprocessor Communication Mode)
  • Half duplex RS485
  • 256 slaves max
  • PC reliability is acceptable (software, power, hardware)
  • USB network is reliable (power, hubs, connectors, cables)

XMEGA is a gateway between Atmel UART MPCM and USB CDC ACM

XMEGA is a demux (one USB stream to one stream per slave)

A USB driver in the PC is a mux (multiple virtual serial ports into one USB steam)

Additional XMEGA tasks are watchdog (USB SOF, USB stream consistency), fail-safe (RS485 to prevent harm, loss, and damage), and real-time (tasks that cannot be on the PC)

The remaining tasks are on the PC (one virtual serial port per slave)

 

P.S.

Applications are being ported away from OS API to web API.

 


http://www.atmel.com/products/microcontrollers/avr/avr_xmega.aspx?tab=documents

...

Atmel AVR XMEGA AU Manual
(file size: 7.2MB, 478 pages, revision F, updated: 04/2013)

http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf

(page 292)

23.12 Multiprocessor Communication Mode
The multiprocessor communication mode effectively reduces the number of incoming frames that have to be handled by
the receiver in a system with multiple microcontrollers communicating via the same serial bus. In this mode, a dedicated
bit in the frames is used to indicate whether the frame is an address or data frame type.
If the receiver is set up to receive frames that contain five to eight data bits, the first stop bit is used to indicate the frame
type. If the receiver is set up for frames with nine data bits, the ninth bit is used. When the frame type bit is one, the frame
contains an address. When the frame type bit is zero, the frame is a data frame. If 5-bit to 8-bit character frames are
used, the transmitter must be set to use two stop bits, since the first stop bit is used for indicating the frame type.
If a particular slave MCU has been addressed, it will receive the following data frames as usual, while the other slave
MCUs will ignore the frames until another address frame is received.
23.12.1 Using Multiprocessor Communication Mode

...

https://github.com/chilipeppr/serial-port-json-server

Serial Port JSON Server is a websocket server for your serial devices. It compiles to a binary for Windows, Mac, Linux, Raspberry Pi, or BeagleBone Black that lets you communicate with your serial port from a web application. This enables web apps to be written that can communicate with your local serial device such as an Arduino, CNC controller…

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having read through all the comments, I'm now considering using either RS-485, Ethernet, or CAN. I'll read up on them all properly in due course, should I have any queries I'll be sure to post them here.

 

gchapman wrote:

Assumptions :

  1. All 'Slave x' are AVR MCU with UART MPCM (Multiprocessor Communication Mode)
  2. Half duplex RS485
  3. 256 slaves max
  4. PC reliability is acceptable (software, power, hardware)
  5. USB network is reliable (power, hubs, connectors, cables)

 

1. Yes

2. Full duplex actually

3. Yes

4. Yes

5. Yes

 

gchapman wrote:

  1. XMEGA is a gateway between Atmel UART MPCM and USB CDC ACM
  2. XMEGA is a demux (one USB stream to one stream per slave)
  3. A USB driver in the PC is a mux (multiple virtual serial ports into one USB steam)
  4. Additional XMEGA tasks are watchdog (USB SOF, USB stream consistency), fail-safe (RS485 to prevent harm, loss, and damage), and real-time (tasks that cannot be on the PC)
  5. The remaining tasks are on the PC (one virtual serial port per slave)

 

1. Close - at the moment I was thinking of using a UART-USB converter such as an FTDI FT232RL as it'll be quicker & easier, but USB CDC ACM is a possibility of course.

2 & 3. Hadn't considered the USB communication in this much detail yet but that does sound like a good approach.

4. The XMEGA will have a little more to do than that but yes, along those lines.

5. Yes. The PC will be running a UI application for the machinery and will handle the bulk of the application. The hardware is just a means of controlling the machinery, the UI will tell it what to do.

 

Going back to 2 & 3. What I was thinking about was simply have the PC treat the USB port connected to the XMEGA as a serial port, and with every message packet send and source and destination address. When the XMEGA receives the packet, it checks the destination (as well as error checking obviously) if the packet is for the XMEGA it processes it, else it passes it on the it's intended target on the RS-485/ Ethernet/ CAN bus.

Similarly, when the XMEGA receives a message from a slave on the bus, it either processes the message itself, or passes the message on to the PC depending on the destination address (or even to another slave on the bus unless the interface I decide to use has the ability of slaves transmitting to slaves, such as CAN as mentioned by Jim a few posts ago

 

ki0bk wrote:

You might consider using CANbus, since it is multimaster any module can talk to any other module, and is multi-drop similar to 485. 

 

A little bit more background info that may or may not be of importance or interest... The PCB that features the XMEGA will not only serve as a master for the RS-485/ Ethernet/ CAN bus, but will also serve as the main control board. Essentially we have a 'base' model machine. This will all be controlled by the main control board. Then on top of this we have add-on options, that enable the base machine to be configured to whatever the customers needs and spec are. Each one of these add-on options will essentially be a slave/ module.

 

Thanks again to everyone who has contributed so far.

 

EDIT: 

gchapman wrote:

P.S.

Applications are being ported away from OS API to web API.

 

I saw someone mentioned this on another thread (it might well have been you in fact!) and I did look into it and I'd like to do this myself, however I can't see it being possible due to the fact that there is a vision system involved, consisting of two cameras and a frame grabber which connects the host PC.

Last Edited: Fri. Jan 27, 2017 - 11:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the PC's job?

 

What happen if the PC's USB connection go down?

 

For industrial use I would do something like this :

 

http://www.danbit.dk/da/mini-pci...  

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would just use MODBUS/RTU over RS485. 

Industrial de-facto standard, pretty much of other industrial can communicate over MODBUS/RTU over RS485

Alexander

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very similar to my application:

(Real-time peer-to-peer communication through RS485)

 

CDBUS VSP

 

The CDBUS protocol can automatic avoid collisions as the same way as the CAN bus, you can take a look at:

https://github.com/dukelec/cdbus_ip

https://github.com/dukelec/cdbus...

Last Edited: Tue. Jun 12, 2018 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From all that you said in post #12 CAN seems the best. At least if the base board controller is kind of busy. RS485 requires polling, and depending on the intended network performance my be heavy polling. I'm only a bit reluctant about CAN because the AVRs (including xmegas) are not CAN-friendly. You'll need external CAN controllers (including on the slaves).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
The company I work for design and manufacture industrial machinery

Then surely the company in those 10 years has set some sort of precedent for industrial comms, and settled on one of the commonly used industrial protocols. I'm surprised your technical director hasn't mandated the choice here based on what your customers will accept.

 

If there is even the slightest chance you may wish to connect a 3rd party vendor's sensor or controller to your bus then you should choose one of the many industrial "standards".

 

Oh - here's an opportunity to write this well known quote : "The good thing about standards is that there are so many to choose from".