RS-485 vs Ethernet for a large automation system network

Thread Starter

zazas321

Joined Nov 29, 2015
936
I am working on a automation system where 1 raspberry pi is running a server and a database. I need this raspberry PI to communicate to multiple slave devices (such as arduino UNO or NANO or other simmilar board). The number of slave devices might be up to 50.

I have created a server on my raspberry pi and using QT Creator to make querys and that part works fine. My major concern is how to make the raspberry PI talk to to slave devices and vice versa.

The slave devices have sensors connected to it and based on certain actions they will need to send a message to the raspberry PI which will then add/remove items from the database. The raspberry pi will be also sending some messages to the slaves..

Initially, I was thinking about using an RS485 and connecting all slaves in a daisy chain, as shown below:
1593767995861.png
each slave device will have to have an LTC1480 or simmilar.


Would using LAN network to connect all devices together make more sense? Would that even be an option when considering large amount of slave devices? Any ideas? Thanks in advance
 

Deleted member 115935

Joined Dec 31, 1969
0
485 is the old way,
very reliable, PROVIDED, the noise is low, the end termination is in place, and the earths of all devices are very similar.
also needs little hardware.

Ethernet is the new way.
advantage, its an isolated system, so voltage does not matter, very noise immune , both at the protocol level and the actual wiring . Infinitely expandable, over any distance, it even reaches space now, but requires more hardware / silicon and tends to have a larger latency.


For reference, cars used to use a system similar to 485, but now use a two wire Ethernet,

https://en.wikipedia.org/wiki/Fast_Ethernet#100BASE-T1
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
Thanks for the answer.

Would you suggest how would I connect such system together using ethernet and how exactly would I communicate to individual slave boards using ethernet? I would assume that I would need to get an Arduino ethernet shield which would allow me to connect to the same network. Dont need to worry about the raspberry PI since it has ethernet port available. How would I then transfer the data between the two? Lets say if I want to turn on the LED on the arduino from the raspberry PI
 

Irving

Joined Jan 30, 2016
3,845
What distances are you looking at, and what latency can you endure?

CANBus and Ethernet-T1 are limited to 15m, but are fast - CAN 1Mbit, T1 even faster (its 66MHz but 3bit signalling, so crudely 22Mbit). Proper Ethernet is good for 100s of metres.

RS485 can go much much further, but slower, typically below 100kBps, that's why its used for factory automation.

Your last question suggests you don't have enough knowledge to do this from the ground up. You need to define a set of high-level messages, eg LED_ON, LED_OFF and an addressing schema. With Ethernet the addressing is done for you, its the IP address. The other systems have their own schemes. With ethernet you open a tcp socket to establish a point-to-point connection to the recipient of the message (who is listening for such a request) and transmit your message as a string of bytes. The remote end receives the message, acts on it and acknowledges the command. The connection is then broken, or not, depending on your overall scheme.

There are libraries and other packages to help, but you have to do most of the grunt work. More importantly you need to design an appropriate message set and protocols for non-delivery, errors, etc. Again, various such do exist but you need to identify which are suitable for your needs and evaluate them.

Raspberry PI is relatively easy as it runs Linux which has the underlying bare-bones of this all natively built-in. Arduino is a different story... that may need considerably more work, depending on which shield you use and what software is available - have a look here for some info, below is some sample code to receive and print a string of text... copied from the example code, if you can follow that you're in with a chance! You might consider alternative devices with built-in wifi/ethernet that are more suitable (ESP32, some STM32 boards, etc.) as Arduino is limited by program/memory size.

Code:
void loop() {
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
  if(packetSize)
  {
    Serial.print("Received packet of size ");
    Serial.println(packetSize);
    Serial.print("From ");
    IPAddress remote = Udp.remoteIP();
    for (int i =0; i < 4; i++)
    {
      Serial.print(remote[i], DEC);
      if (i < 3)
      {
        Serial.print(".");
      }
    }
    Serial.print(", port ");
    Serial.println(Udp.remotePort());

    // read the packet into packetBufffer
    Udp.read(packetBuffer,UDP_TX_PACKET_MAX_SIZE);
    Serial.println("Contents:");
    Serial.println(packetBuffer);

    // send a reply, to the IP address and port that sent us the packet we received
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
    Udp.write(ReplyBuffer);
    Udp.endPacket();
  }
  delay(10);
}
 
Last edited:

Thread Starter

zazas321

Joined Nov 29, 2015
936
First of all thanks for your answer.
The distance that im looking to get is about 20m lets say. Since ethernet sounds bit too complicated for me yet. I better off try to build rs485 daisy chain. The only concern is that I can only have 32 devices on a single rs485 bus. Since I have 3 usb ports on raspberry pi and could use all of them for rs485 and would give me 96 slaves right
 

Irving

Joined Jan 30, 2016
3,845
Even with RS485 you still have much of the same code to write. The thing is, once you have an abstracted transport, you can do something easy like

Send(node27, LED3_ON)
temp6 = getTemperature(node6)

or even better

Node27.ledOn(3)
temp = node6. getTemperature()

Leaving you only worrying about the business requirements not the plumbing. The question then becomes, Can I find software off-the-shelf that does the underlying transport? Whether the physical medium is Ethernet, RS485 or carrier pigeon is just a decision about speed, latency, cost, physical implementation, etc.

I've done this many times. The tricky bit is with low-end devices such as Arduino because of their limited memory. RaspberryPi and PC are much easier. But you still have to define your message set & structure, error handling & recovery processes, etc. and getting that right and not creating an unmaintainable nightmare for the future is a substantial bit of work.

So, my question to you is how much experience of implementing such systems (not just writing the code) do you have? We can help, but it's going to be a steep learning curve if you're new to the game.

Feel free to PM me if you want to discuss further 'offline'.
 
Last edited:

Irving

Joined Jan 30, 2016
3,845
Add on to above.

The code I showed for the Ethernet shield is one level below the abstraction I mentioned. It's at the level of

Send(address, raw_data)

Does such software exist for RS485? I don't know off the top of my head as its been a while since I've used it, most of my recent work has been with CANBus and LoRaWAN.

A little digging threw up this RS485 library
https://www.gammon.com.au/forum/?id=11428

It's at a similar level to the Ethernet one, but it's a start maybe.
 
Last edited:

Thread Starter

zazas321

Joined Nov 29, 2015
936
Thanks for the help guys. To answer to Irwing question about implementing such systems- i do not have such experience. I just have some basic knowledge ant worked with i2c,usart,spi, various gpio operations thats about it. Well if I choose to go etherner route it concers ne that I will need a board with built in ethernet capabilities? Such boards will come at a cost, and when i need 50 of those, that will be a concern.

On the other hand, implementing rs485 modbus or simmilar should be easier in terms if hardware. Just not sure what are the physical limits how many i can have on a single bus
 

Irving

Joined Jan 30, 2016
3,845
Looking here, they supply both Ethernet (@ 21euro) and RS485 (@ 27euro) as well as a common ModBus library which uses either physical infrastructure. That looks potentially a good place to start, though still requires a fair bit of programming to get to the 'easy' solution. On that basis Ethernet is cheaper and simpler to implement.

Of course you may choose to implement an ad-hoc/on-the-fly approach, but once you have 50 nodes and a few functions per node you'll wish you'd started with a more structured & maintainable approach, which will also make testing easier. You start with one node/one function and expand the capability as you go. That first function wil be a simple 'ping' - are you there & whats your status? which will set up the framework with error handling etc going forward and make life much simpler.
 

Deleted member 115935

Joined Dec 31, 1969
0
You might want to look at the teensy range of arduino compatible boards.

https://www.pjrc.com/store/teensy41.html

They 4.1 for instance has ethernet built in.

The hassle I have had with Rs485 and similar, is termination and reliability.
One bad connection or broken sensor and the complete line of sensors becomes un reliable.
where as Ethernet , being a start network , the broken sensor only takes itself down.
I ended up with a mixed network, Ethenet between "nodes" ,both wireless and wired , and then hard wired local RS485 , with wires in conduit ..

It all depends what your controlling / monitoring and the consequences of a fault.
 

Irving

Joined Jan 30, 2016
3,845
Modbus is pretty ancient, its original intent was to connect industrial PLC together and its limited understanding of devices shows. At the low level a temperature would be represented by a modbus register 16bit integer, or two 16bit registers if a floating point but thats a kludge as modbus doesn't support 32bit values natively. An LED thats on or off would be a modbus 'coil'. You definitely would want to write a higher level abstraction for your sensors. Here's a Youtube video giving an overview of modbus (and IMHO a good arguement not to use it!).

Personally I'd go straight to Ethernet, skip the modbus and look for Arduino-like boards that have Ethernet built in. I currently use ESP32 Wemos boards with built-in wifi to avoid any cabling (other than local power) but that might not work for you (though if only 20m radius that makes a lot of sense to me - depends on your environment). I buy these at less than £5 ($6.25) each in 20s.

There's an ESP-specific protocol ESP-Now which looks interesting, and is being touted as an IoT device-to-device protocol. Ive not used it but it might be a good basis for your needs.

If you wanted just Ethernet and no additional power wiring then this ESP32/PoE board looks a good, but pricy, option.
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
Thanks for all suggested ideas! Well I had a look at some development boards with ethernet built in. Since I want my system to be very robust and reliable , i probably should be looking at boards that have wired ethernet board instead of those small chips such as weemos mini that only support wireless.
https://www.freetronics.com.au/products/etherten#.XwC2oTOEadM

Or previously suggested ESP ethernet board with ethernet port

Though such boards cost 50€ each so to make 50 of those would come at a high price. I am not too sure whether the speed and reliability of such boards are worthed over using arduino nano + rs485 driver which would probably be half of the price. I dont really mind spending an extra 20€ or more per node to make system reliable and fast just need to know whether its that much better
 
Last edited:

Irving

Joined Jan 30, 2016
3,845
The other consideration I alluded to before is that any board offering true Arduino compatibilty with the ATmega328P MCU is severely limited on program memory, RAM and a 16MHz clock speed... and that includes the nano. Those 'tiny' ESP boards offer a 240MHz dual core processor with 4Mbyte program and 4Mbyte RAM. What sort of environment are you operating in? If you're looking for bullet-proof reliability steer clear of the cheap RS485 boards with just a bare 1480 chip. You need a board with ESD protection, and preferably galvanic isolation via a transformer or optical isolation. You get that natively with Ethernet and obviously with WiFi.
 

dendad

Joined Feb 20, 2016
4,451
If you go with RS485, have a look at Monsun's range of isolated RS485 drivers. here is one, a bare board version.
MorsunRS485_BB.png
There are quite a few others too. Potted like this one.
MorsunRS485_Potted.png
See https://www.mornsun-power.com/html/products/48/rs-485-transceiver-module.html
They have a range of other neat devices too!
I have no connection with them other than having purchased parts.

If you go with un-isolated drivers, use DIP parts in sockets so they can be replaced if needed. And add ESD protection and a common gnd cable shield connection between the nodes.
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
The other consideration I alluded to before is that any board offering true Arduino compatibilty with the ATmega328P MCU is severely limited on program memory, RAM and a 16MHz clock speed... and that includes the nano. Those 'tiny' ESP boards offer a 240MHz dual core processor with 4Mbyte program and 4Mbyte RAM. What sort of environment are you operating in? If you're looking for bullet-proof reliability steer clear of the cheap RS485 boards with just a bare 1480 chip. You need a board with ESD protection, and preferably galvanic isolation via a transformer or optical isolation. You get that natively with Ethernet and obviously with WiFi.

Those boards will be only responsible for reading sensor value/toggling LEDS occasionally and sending/transfering data to the control board/server (raspberry pi). It will be implemented in small factory type environment. How reliable are those wireless boards? Since the boards will be enclosed and hidden Im worried i might miss signal or data with wireless
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
If you go with RS485, have a look at Monsun's range of isolated RS485 drivers. here is one, a bare board version.
View attachment 211385
There are quite a few others too. Potted like this one.
View attachment 211386
See https://www.mornsun-power.com/html/products/48/rs-485-transceiver-module.html
They have a range of other neat devices too!
I have no connection with them other than having purchased parts.

If you go with un-isolated drivers, use DIP parts in sockets so they can be replaced if needed. And add ESD protection and a common gnd cable shield connection between the nodes.
Thanks for the advice
 

Deleted member 115935

Joined Dec 31, 1969
0
Industrial environments can be bad,
what level of guarantee / service agreement are you giving with this ?

Reliability of communications comes down to the protocol as much as the medium.
wireless, yes it can be blocked, but its very rear that the block is 100 %
your only over 20m, so the signal is going to be strong,
The protocol is used to increase the reliability,
TCP/IP has resilience inherent, WiFi and mesh networks add more layers of resilience,
the data rate goes down as the reliability is increased.

A mesh network might be worth looking at for reliability, such as LoRaWan
 

Irving

Joined Jan 30, 2016
3,845
If you write your system correctly you can ensure data won't get lost, or, worst case, you are notified of that event. There are many things you can, and probably should, do in a high-reliability environment...

1/ Always timestamp your data when collected, and build that into your message structure. For belt & braces, timestamp when transmitted too. To sync all nodes, have your master transmit a time signal regularly. Think about the resolution of the timestamp. Reporting a temperature every 5 seconds probably doesn't need millisecond resolution.

2/ Use a store and forward mechanism, such as MQTT. This way a node that's out of communication can continue to capture and store data, which then is forwarded automatically when communication re-established. Never rely on direct end-to-end communication unless latency/speed are critical - from what you've said that's not the case, and generally isn't in a factory environment, reporting at 1 - 50 times/second is not uncommon (on RS485 with 50 nodes and a 200byte payload at 115200baud thats less than 50 frames/second system wide). If you need control in the millisecond timeframe you should be doing that locally;

3/ For nodes that don't report regularly, have a background 'ping' that's checking they are present; Either from node to server with server alerting on a missed ping, or server to node with an alert on no response. Again, consider how many frames/second your system can support.

4/ Use checksums/CRC to ensure data is not corrupted in transit, more sophsticated schema can correct 1 or 2 bit errors but havea performane cost. This is only needed for serial comms such as RS485. Ethernet/wifi does it for you;

5/ For WiFi there's now an option to use mesh technology where a node that can't reach the server can route via another nearby node that can. This is now built-in to the ESP32 firmware. This technique is fast becoming the norm for IoT, and is common in other environments e.g. 868MHz ZWave for wireless HVAC control systems and home automation;

6/ If using RS485 consider a time division multiplex solution to minimise traffic and be more deterministic. Here each node has an address eg 01 - 50. Each listens for a start request from the server, waits a time period related to its address then transmits a payload, whether or not it has data of interest. At 115200 a 200byte payload takes 17mS, so if each waits 20 x address mS, 50 nodes can report each second without contention. A 100byte payload can accomodate 100 nodes. If it was a server request/node respond protocol then the overall system transfer rate would be much slower due to additional traffic, contention/collision avoidance, etc. TDM can be implemented over Ethernet/WiFi as well but is more suited to low speed networks - I've used it in the past for reading data from 512 nodes on a wide area low-power radio network (a forerunner of smart metering).
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
Industrial environments can be bad,
what level of guarantee / service agreement are you giving with this ?

Reliability of communications comes down to the protocol as much as the medium.
wireless, yes it can be blocked, but its very rear that the block is 100 %
your only over 20m, so the signal is going to be strong,
The protocol is used to increase the reliability,
TCP/IP has resilience inherent, WiFi and mesh networks add more layers of resilience,
the data rate goes down as the reliability is increased.

A mesh network might be worth looking at for reliability, such as LoRaWan
This is an internal project so I want the system to be reliable for my own sake.
 

Thread Starter

zazas321

Joined Nov 29, 2015
936
If you write your system correctly you can ensure data won't get lost, or, worst case, you are notified of that event. There are many things you can, and probably should, do in a high-reliability environment...

1/ Always timestamp your data when collected, and build that into your message structure. For belt & braces, timestamp when transmitted too. To sync all nodes, have your master transmit a time signal regularly. Think about the resolution of the timestamp. Reporting a temperature every 5 seconds probably doesn't need millisecond resolution.

2/ Use a store and forward mechanism, such as MQTT. This way a node that's out of communication can continue to capture and store data, which then is forwarded automatically when communication re-established. Never rely on direct end-to-end communication unless latency/speed are critical - from what you've said that's not the case, and generally isn't in a factory environment, reporting at 1 - 50 times/second is not uncommon (on RS485 with 50 nodes and a 200byte payload at 115200baud thats less than 50 frames/second system wide). If you need control in the millisecond timeframe you should be doing that locally;

3/ For nodes that don't report regularly, have a background 'ping' that's checking they are present; Either from node to server with server alerting on a missed ping, or server to node with an alert on no response. Again, consider how many frames/second your system can support.

4/ Use checksums/CRC to ensure data is not corrupted in transit, more sophsticated schema can correct 1 or 2 bit errors but havea performane cost. This is only needed for serial comms such as RS485. Ethernet/wifi does it for you;

5/ For WiFi there's now an option to use mesh technology where a node that can't reach the server can route via another nearby node that can. This is now built-in to the ESP32 firmware. This technique is fast becoming the norm for IoT, and is common in other environments e.g. 868MHz ZWave for wireless HVAC control systems and home automation;

6/ If using RS485 consider a time division multiplex solution to minimise traffic and be more deterministic. Here each node has an address eg 01 - 50. Each listens for a start request from the server, waits a time period related to its address then transmits a payload, whether or not it has data of interest. At 115200 a 200byte payload takes 17mS, so if each waits 20 x address mS, 50 nodes can report each second without contention. A 100byte payload can accomodate 100 nodes. If it was a server request/node respond protocol then the overall system transfer rate would be much slower due to additional traffic, contention/collision avoidance, etc. TDM can be implemented over Ethernet/WiFi as well but is more suited to low speed networks - I've used it in the past for reading data from 512 nodes on a wide area low-power radio network (a forerunner of smart metering).
Considering you mentioned Mesh network. I have used Zigbee once, that was a cool mini project. So that would be an option tooI guess..

Well i see there are quite a few options available I guess i just pick one and work my way from there. It would be much easier when I actually try do some things.. since I want my system to be expandadnle in the future i better off go with ethernet/esp solution. I might try wireless but dont want to spend too much time working with wireless ethernet solution and then realizing its going to a headache.

Id rather spend more and have a least amount of headache/problems

Not sure why but anything that does not have a physical wire such as wirelless internet does not sound too reliable.. the person operating the devices will have 0 knowledge about electronics so if the signal or data is not properly trandsmitted/received , the operator might make a very bad mistake. I need my slave devices to ALWAYS respond when I need them to and always trasmit whe I need them to
 
Last edited:
Top