Has anyone seen a commericially available "eavesdropping" Modbus Master
driver? What I'm trying to do is poll PLCs using MODBUS from a National Instruments Lookout system. No problem. The trick is, I want to have a backup Lookout system with all the same data. This is a MODBUS implementation via satellite. 6 second turnaround. The two PCs are miles apart and don't have any connection other than the Satellite. If I were going to do it custom, I'd write an "eavesdropping" driver and stick it in a PC between the backup Lookout and the satellite system. It would listen to the polls from the actual master over the MODBUS system, as well as the replies, and build a database from which to answer polls from the backup PC. Of course, I'd rather buy something that can be easily maintained than write something custom. Ideas?

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
(915) 498-6080 ext 232
[email protected]

 

George,

National Instruments Lookout software normally provides several ways to accomplish what you are attempting to do without the need for additional software. The easiest method is to use the built-in redundancy features of Lookout, however, since the two computers do not share an ethernet link and may only communicate via satellite, this option is not useful in your case. An option that will work is to create a Modbus Slave object on your primary computer and link all the registers from the Modbus object that talks to your PLC to the Modbus Slave object. The back-up computer can now poll the primary computer as if the primary computer was a modbus device to get the data. You can further set up the Modbus Slave object with a different address and monitor the communications to the slave object so that if you no longer get information from the slave object, you can assume that the primary PC is offline and choose to directly communicate with the PLC.

Regards,
Aaron Gelfand
National Instruments

 

George,

I am confused. Shouldn't your backup Lookout system simply poll from the master (APP to APP Comns via TCP/IP), or more efficiently have the master send it updates on an exception based algorithm ? Then if the master fails, the backup would automatically run it's Modbus driver locally to acquire the data (You still have the problem of not being local to the I/O, which your listening device does not solve either?). When the master returns to life, the two apps would then automatically synchronize info gathered by the backup. I am not familiar with Lookout, but this is how our drivers work for hot-backup configurations, which must be common.

Another solution I have seen implemented is by employing a middleware app\device that polls the I/O for you (Master), then acts as a Modbus slave for all downstream devices (Your Primary Lookout and Backup) on another port. Some PLC manufacturers provide this capability. Writes may be tricky for you in this arrangement, as you may have to define triggers between the slave writes and the Master Writes to the real I/O. We have also done the same with our HMI ( its a Master to the I/O and Slave to other independent apps ) to interface OEM equipment replacing DCS's in power utilities.

Barry Baker, P.Eng.
VTS Software
www.trihedral.com

 

Miille Applied Research makes a device called the OmniCom that will allow two Modbus Masters to poll the same Modbus Slave devices over a common communications link. I've tried it and it works.

"http://www.miille.com/":http://www.miille.com/

 

Hi Rob & George,
Thanks for the invitation to discussion. Sounds like the Spartan/Calta solution was a dual ported mux/arbitrator to the SCADA radio. We implemented a solution like that some years ago to allow two SCADA masters from different vendors access to the same radio circuit. Our eavesdrop master was a different solution for a different situation.
It is being used to provide a second "workstation" from a field office within the radio path of the master and repeaters, as well as truck mounted workstations.
Our eavesdrop master was implemented in order to allow operators in field service trucks to have access to the information being received by the SCADA master from the RTUs in service in the field. The service trucks could "hear" the SCADA radio circuit, so we implemented an
eavesdrop handler as part of our SCADA master to capture that data. Field service trucks were equipped with laptops and the eavesdrop version of the SCADA master to provide truck mounted SCADA access. George, your solution is certainly possible, as you say, by building an eavesdrop database to repond to master polls. The driving question I would have is whether the remote site actually can see the data being received at the original master site, and what it will cost for the data transmission via satellite to both master sites. In other words, is it technically and economically feasible to listen to the conversation between the hot master and the satellite at any place other than the hot master location, if your only contact is the satellite? Once that is clear, then progress can be made toward nailing down a solution.
[email protected]