we have modbus over ethernet connection between yokogawa DCS and unknown SCADA system and Wonderware historian.

The problem is most of the time communication is okay but it frequently dies for unknown reason and gives communication errors and no data.
Does anyone have any solution or info?

 

Does any of the devices go down? sometimes if one device fails, the whole network stops communicating till that device goes back online or the connection retry attempts have expired for that polling cycle. This is something to watch for.

Have you considered using OPC for this? OPC Servers have an advanced polling engine that polls all devices and exclude the disconnected devices from the polling cycle. Once the disconnected device goes back online, it gets added back to the polling cycle. This will prevents any delays when any device goes down when having multiple devices into under one communication channels.

For the Modbus use this one: http://is.gd/f0XAZ
Yokogawa: http://is.gd/f0XDG

Hope this is helpful

Wassim Daoud
Global solutions architect

 

Put a sniffer on it like Observer or Wireshark to trap packets to see if it's a protocol thing..

Also have a PING trap running to see if the connectivity drops... if the ping goes away then it might be a firmware issue, cable issue, router/switch issue, or a broadcast storm that takes the device offline..

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com

 

Thanks guys

we considered to use OPC for this application. Hope it will solve the problem.

No none of the device goes down? I am still wondering what is the actual problem causing the issue?

thanks for your reply anyway.

Will P.
Technical Advisor

 

Late reply - Yokogawa DCS does not support Modbus Slave - so I can’t imagine that you are really using Modbus to communicate with your HMI & Historian?

I suggest you go looking on the Historian / HMI for log files and associated clues they contain as to the reason for the comms outage.

Option 1.
They will be using a proprietary PI / Wonderware add in to communicate directly to the FCS

Option 2.
They will be using your engineering station as an OPC server using Yokogawas OPC libraries to read data (ok for a historian - but dodgy for a HMI!)

PB

 

Some suggestions:

- Try to connect to port 502 on the slave to see if it has the correct port opened and is listening (eg telnet mymodbushost 502)

- Some things that may disturb slaves are querying for items that are not addressable (above highest available coil/register) or sending from a master with dual ethernet cards and no way for the slave to route to the other network

- Try to probe with a third party modbus tool, for instance Ruby Modbus from the command line (free, open source), or the omnimbt tester tool from omni flow.

- As suggested, wireshark will probably give you a good indication of the root cause

- If the modbus is used too heavily, some slaves are not able to keep up with traffic. In this case it will shut down ports, until a timeout occurs and they are released. The client probably has a limited number of simultaneous master sessions available, often like 4 in my experience.

- Look at the log files in the SMC (quite obvious, so I guess you have this one covered)

 

A couple of Ethernet issues to watch:

1) make sure you 'hard-code' as many Ethernet port settings as possible - probably at 100Mhz half-duplex only, because if a device thinks it is talking half-duplex and the switch thinks full-duplex, you have a very high error rate.

2) does the connection at times sit idle for 5 minutes? Many/most IP layer 3 devices (routers, NAT firewalls, etc) will silently trash an idle TCP/IP connection after 5 minutes. So the client now has a dead socket, but cannot know that until it tries to use it again. So you need to either make sure to talk every few minutes or enable TCP Keepalives, which by default will NOT be on for most Windows systems. Plus you'd need to drop the keepalibe time to 4.5 minutes, because they will default to 2 hours ... which won't help you if 5 minutes is the drop-dead idle time.

 

I have a similar issue with a CentumVP application talking to a GE Versamax. After analyzing the packets, it appears that the DCS is polling too fast and overflowing the PLC. Is there a way to slow the polling rates of the DCS Modbus master?

I am using an ALE111 with the Modbus/TCP driver.

 

Hello,

Pl. check the following and correct under ALE111 Settings.
Got o the specific ALE111 Module and right click with mouse(System View--FCS---ALE111).

1. No. of connection retries:

2. No reply time out:

3. Interval of No. of Retries:

You need to set the above to tune up the communication in line with PLC. More over the most important part of seamless communication is to effectively break down the packet sizes(especially in the cases of AI/AO)and selecting the Correct device types at DCS end.

Good luck!!

>I have a similar issue with a CentumVP application talking
>to a GE Versamax. After analyzing the packets, it appears
>that the DCS is polling too fast and overflowing the PLC. Is
>there a way to slow the polling rates of the DCS Modbus
>master?
>
>I am using an ALE111 with the Modbus/TCP driver.