Modbus TCP Device Connection

Hi, looking for some input for something that should seemingly be simple, but isn’t.

I recently just replaced an old DirectLogic PLC with a new P3-550E Productivity PLC. Device uses same IP address, same port# etc. but will not connect to Ignition Gateway. I can ping the PLC through the network and program the PLC through the network. Our ITS team says that the issue is not in their end and the firewall is not blocking traffic but that they can see odd traffic like a request is being made but no response.

I have tried everything I can think of…..

  1. Restarted Gateway
  2. Deleted and reconfigured Device
  3. Confirmed all IP address and port info on both Ignition and PLC
  4. Tried another Test Gateway with updated Modbus driver
  5. Made sure all my tags were enabled so that there was something for the device to transmit
  6. Adjusted response timeout settings on both ends
  7. PLC is setup for read/write

Nothing has worked…. As much as I’d love to blame ITS I’m hoping that’s not the case because I’ve wasted 2 days on this already.

Looking at the ignition logs the initial Modbus error is “connection timeout”

The modbus driver will timeout after 10 seconds of not reading at least 1 tag.

Ensure your modbus mapping is setup in the PLC. In the productivity series, you must assign addresses yourself.

1 Like

Thank you Matrix, I do have the registers set up in the P3, and individually assigned them in Ignition for example

In P3
Tag Name = Station_Flow
Type=Float 32bit
Modbus Address= 403001-403002

In Ignition
OPC Standard Tag
Tag name = Station_Flow
Type=Float
[Device_Name]HRF3001

Still nothing. Question mark next to tag and diagnostic says “uncertain”

Enable trace in the log for the modbus driver and it'll give you better detail on what's happening. Modbus grabs in sections, so if you've got one address that's incorrect it'll throw errors on a bunch.

Go to the status / log page and change the modbus driver to "TRACE".. make sure you turn it off afterwards or you'll fill the log.

Then you can filter for the device you have the issue with to cut the log size down. Interrogate the packet with something like this: Online Modbus RTU Parser & Modbus TCP Parser (rapidscada.net)

Hopefully that points you at exactly what's wrong!

1 Like

Thanks Josh, these are the continuous errors I am getting

If you're really getting a connection timeout issue then this isn't an Ignition problem quite yet - it's a networking problem of some sort.

Maybe firewall, maybe IT, maybe your PLC simply isn't configured to listen as a Modbus server right now.

2 Likes

I 100% agree. I’m pulling my hair out knowing it’s most likely something I don’t have access or control of.

I just had a thought…. Could a crossover Ethernet cable cause something like this? Our PLC is linked to a cellular router back to our ignition network. Maybe things are getting jumbled.

Yeah I'm with Kevin, looks like a timeout.. either because the data isn't getting through. Use a tool like ModbusPoll to connect directly, removing Ignition's config from the equation. Get ModbusPoll working and it'll be easy to use those settings in Ignition.

What are your tag groups set up as, some field devices might have a low (<1000ms) timeout, so if you aren't polling faster than that you'll have disconnections like this too.

1 Like

I will give that a go; on Friday I may end up taking a demo Ignition gateway directly to the site as well and plug my laptop into it to make sure Ignition will run it directly. Its a definite pain having to make setpoint adjustments via the PLC logic until it gets resolved, but better than site visits multiple times a day.

Also good point on Tag groups, that is the one "different thing" I did for this device (18 other devices on this gateway). I turned polling down to 5000msec since its a cellular site and non critical response time needed. Maybe that is hanging it up.

Try ]1.HRF3001, if 1 is your node ID in the PLC.

Second the suggestion to use ModPoll etc to advance diagnostics.

A little update on this, I went to the location this morning with an updated 8.1 trial version of Ignition and directly plugged into the device. No connection could establish using the ModbusTCP driver. I triple checked my tag references and settings within the PLC to allow it to act as a modbus server. I called Automation Direct tech support to ask if there was something that I am missing because I have multiple Productivity plcs in the system with the same configuration that will connect without issue.

Their guess at this time is firmware issues and Ignition. This device has a much newer firmware deployment than my other devices on the network. Does this sound reasonable? I do have a spare P3-550 cpu with an older firmware version that I can recreate the program in and test, but wanted some input before I go through the effort.

Did you try ModPoll?

Never used a P3, only a couple of P1's, never had to adjust firmware to get modbus to work with Ignition.

Well the problem is solved and the device is connected. Thank you all for supporting me as I worked through different solutions. I still have some unanswered questions because it just started “working”.

  1. I can’t get a solid answer if ITS made a network change to firewall and I will never know

  2. Why wouldn’t the device connect with a direct connection to the PLC via ignition. It was mentioned that maybe I should have used a crossover cable because I was using a straight cable.

  3. Why do simple tasks turn into such a nightmare

1 Like

Most laptops since the late 2000's have inbuilt technology to automatically crossover for you (Auto-MDIX). So a straight through should have worked.

I can't answer your other questions unfortunately :slight_smile:

1 Like

That blatantly means IT did it.

Sorry this isn't timely.
For any future readers:
In this situation, there are various modbus polling programs available online. If you find one that works regularly for you then in a situation like this it serves as a good doublecheck that Ignition settings are / are not the problem.

If your third party client also fails:

If you're going from one side of a firewall/router/managed switch to another, you can plug a laptop into an equivalent place to the PLC (e.g. insert a $50 unmanaged switch on the same port of the firewall/router/managed switch as the PLC) and use wireshark to prove that the modbus packets are / are not making their way to the PLC.

There's nothing like showing up to IT saying, "I can see my port 502 modbus packet on this side of your managed switch / firewall / whatever, but not the other" to focus their attention on where the problem is.

PS Ignore the old crossover cable thing.