Modbus v2 issue when using node address

I have an Ignition installation that communicates with two PLCs.

The first is a Momentum Compact PLC that is hooked up to a serial to Ethernet adapter. This PLC experiences no communication problems. In fact, communication with this PLC is fast and reliable.

The second PLC is a Tesco proprietary PLC with a built in Ethernet port. Forgive my ignorance of the exact PLC model. I am not terribly well versed in Tesco PLCs. The PLC has no communication problems with the local HMI and I have a very strong Ethernet radio link to the site over Ubiquity radios.

The Tesco PLC requires the use of a node number so a typical address might look something like this: [W34]1.HRF874. All of my Igntion SQL tags for this site cycle between the following qualities: Good, Unknown, Bad, Unknown (lather, rinse, repeat). I have changed parameters of the scan class as well as the actual Modbus v2 driver, but this error persists.

During development I set up a test Schneider M340 with the exact same IP address as the production Tesco PLC and communication was solid. No errors ever presented themselves and the quality for the tags is always good.

Tesco has looked at their PLC and have found no errors and, as I already mentioned, the local HMI does not experience communication errors. This leads me to believe there is something I am missing in my setup of the Modbus v2 driver when using a node address.

Anyone have any insights?

What scanclass rate(s) are you using for tags on the Tesco PLC?

I have tried several different scan class rates, all under direct polling mode. I have tried increasing the poll rate to 2 seconds and 5 seconds while increasing the stale timeout to 15 and 20 seconds.

I have always used Direct polling mode and always used Subscribed as the OPC Data Mode.

The Modbus driver has also undergone some experimentation. I have tried increasing the stale timeout several times and I am currently at 30 seconds. In the advanced options, I have decreased the number of holding registers, input registers, coils, and discrete inputs to various values. I have tried 100 and 50, but based on the local OIT configuration I am currently at 64.

Again, based on the local OIT options I have also disabled “Allow Write Multiple Coils Request”. All other multiple requests are still enabled.

Is there anything showing up in the log files? You can attach them to this post or email to support and we’ll take a look.

Not sure about the log files. It is a remote site so I do not currently have access. I will be going up there in the next couple of weeks though. I will get them while I am up there and post back here.

I should also mention that a colleague of mine experienced this same problem when using a 4-port serial to Ethernet device server. Each serial port on the server was addressed by the node number in the OPC Item path. It as a Moxa NPort IA5450A I believe.

The problem only went away for him when he configured devices that were talking to all 4 ports. I don’t know if that helps or not, but I thought that it was suspicious that he had the same problem when talking to less than 4 devices.

In that case, go to the levels tab, type in ‘Modbus’, find the logger with the troublesome device name in it, and it and all of its sub-loggers to DEBUG.

Make sure things log at least through one quality cycle as you described, and THEN export them.

It will also be good to know what version of Ignition it is.

Thanks for the directions.

Ignition version is 7.5.6

Did you ever get a chance to visit the site and retrieve logs?

I did get a chance to visit the site again, but I discovered that there was a failure with one of our radios so I could not gather any logs. The radio has been replaced and I am going to be visiting the site again sometime in the next 2 weeks. I will gather the information then.

Well, I found the issue. After much troubleshooting, the problem was with the OPC Item Path that I was using in some of my tags.

The PLC datamap that I was given listed a lot of alarms and other status indicators in the 1x register range. I guess that this brand of PLC can write to these registers internally (or maybe they are just exposing internal memory via these registers to avoid incidental writing from others?). During testing I used a script to change a lot of these over to 0x registers, because that is what my test PLC had.

When a tag with an OPC Item Path of [W34]C1342 (or some other large coil address) that the PLC did not have addressed was requested the client PLC didn’t send back any error information or the Ignition Modbus driver doesn’t recognize Modbus error codes (I didn’t investigate which is true). So Ignition timed out, reset the connection, and started polling again. This is why I had my connection state shifting between good, unknown, bad, and unknown. A painful fix since I had to go through each tag one-by-one and re-verify the register address, but it eventually worked out.

[quote=“jmartell”]Well, I found the issue. After much troubleshooting, the problem was with the OPC Item Path that I was using in some of my tags.

The PLC datamap that I was given listed a lot of alarms and other status indicators in the 1x register range. I guess that this brand of PLC can write to these registers internally (or maybe they are just exposing internal memory via these registers to avoid incidental writing from others?). During testing I used a script to change a lot of these over to 0x registers, because that is what my test PLC had.

When a tag with an OPC Item Path of [W34]C1342 (or some other large coil address) that the PLC did not have addressed was requested the client PLC didn’t send back any error information or the Ignition Modbus driver doesn’t recognize Modbus error codes (I didn’t investigate which is true). So Ignition timed out, reset the connection, and started polling again. This is why I had my connection state shifting between good, unknown, bad, and unknown. A painful fix since I had to go through each tag one-by-one and re-verify the register address, but it eventually worked out.[/quote]

The driver does recognize modbus error codes when they’re returned. It’s not uncommon for devices to simply not respond when they receive a request they don’t like, which explains the behavior you were seeing.