Has anyone used a data acquisition and control system with dual redundant RS-485 network? If so, i would like to know if the system works reliably and what HMI you have used and what communication protocols you have used? Thanks!
In a previous life I did custom front-end processors for truck-loading systems with dual RS-485 to the bay controllers - so maybe that's a bit of a cheat per your question. The front-end processor actually was accessed by ARCnet from an Oracle database system and Iconics HMI. The HMI was unaware of which of the 2 RS-485 was being used - the front-end processor would load-balance between the 2 lines and auto/fail + auto-recover if any nodes stopping using one of the two links. The HMI did see a bit-map (or coil list) of active/failed links by Modbus/RTU from the front-end processor - which also included Modbus data showing the loading process for the HMI. Failure/recovery of a node thus created an alarm log event in the HMI.
The field wiring was in EX conduits with isolation switches etc - the main goal of the dual RS-485 had been during active loading none of the field junction boxes could be opened to troubleshoot RS-485 problems. So the customer demanded a system that could run for the rest of the day with a faulty RS-485 wire such that maintenance could be done late at night when a block of bays could be idled and declared safe for "hot work".
Things to watch out for: 1) The first system I did had been "sold" by the main contractor with the idea that the RS-485 was looped such as COM1 -> all bay controller -> COM2 and the user expected a "problem" within the system to allow the controller to talk into "both ends" to reach each partial group of the nodes. Obviously, this would work ONLY if all 4 wires of the RS-485 were cleanly severed - which is not likely as a loose screw or broken solid-core wire most likely affected only 1 wire of the 4. Plus even when all 4-wires where cut during factory-testing with full-length wires, running without termination the success rate was very bad & only some nodes at each end of the line would work reliably.
2) But the nice thing about the early designer's wishing full thinking was we easily just doubled the wire cores and since the "loop" design was planned, we ended up with the redundant RS-485 running in opposite
directions: COM1 -> all bay controller ->COM2 and COM3 -> all bay
controller -> COM4. So the front-end processor normally only talked out COM1 and COM4. Thus the first node for the COM1 link was the last node for the COM4 link.
3) COM2 and COM3 were use for an echo-test - every message sent on COM1 was expected to return on COM2 and if they didn't, the controller knew that some of the main-trunk wiring was faulty, as opposed to some drop/tap wiring if one or more devices stopped responding on one channel. This info was also logged by the HMI.
The result was very successful and all tested "single-points of failure" (and many multi-point failures) in the RS-485 wiring caused no overall loss of function.
The Smar LC700 hybrid controller has dual redundant RS-485. It uses the Modbus protocol. It comes with an OPC server (can also be redundant) so it can tie in with any HMI.
