Native PLC query-response protocols (Modbus, EtherNet/IP, Siemens Native, et cetera) are notoriously bad over WAN connections. You need something local to that power meter that exposes a producer-consumer or subscription-based protocol. These do not have WAN problems. (OPC and MQTT are the most popular.)
Hi Phil,
Thanks for the reply. So what you are saying is a local OPC server for this meter and use Ignition to connect this local OPC server?
1 Like
I think Phil is referring to Ignition Edge or other OPC gateways. Your Ignition is connected to the gateway via a complex network link using the OPC protocol, and the gateway is connected to your Power Meter using the modbus protocol (don't exceed one switch in the physical connection).
1 Like
I'm not sure if the issue was resolved but I have run into a similar issue before using Banner Engineering Gateways. This particular modbus device had several embedded Modbus addresses : { "modbusRadio" : 99, "modbusLocalRegisters": 1, "modbusLCD": 201, .....etc}. Furthermore, HR's actually needed to be HRUS when pulling Integers from the modbus device.
Ex:
ns=1;s=[BannerGateway_1]199.HRUS777
Leaving out the 199 prevented an OPC connection as well as using 'HR' instead of "HRUS" .
Thanks for the reply Cliff. I tried to change it from HR and HRUS, they are working now!
But I'm still using 1 instead of 199. Why 199? Can you elaborate a bit more?
Thanks
The slave address depends on your device, 199 should be just an example. If you only have one meter and address 1 works fine, use it. Otherwise, you need to find out the slave address of your meters.
1 Like
Thanks all.
All solved. Hopefully we will keep using these PM800 for long even though they are quite old and no longer supported.
1 Like
To piggy-back off of [nideyijuyidong], the modbus device you are using may have several embedded modbus addresses, each serving a different role. In my case, the device manual specified that the internal modbus address '1' was for R/W 'local' registers (where users can define custom registers [useful when pulling pattern-structured, Ignition-friendly data registers]) and address '199' was direct from a radio/wireless register block. My UDTs used a combination of HRUS's from both s=[modbusDevice]1.HRUSnnnn and s=[modbusDevice]199.HRUSmmmm.
1 Like
One more thing: if you need to create a UDT OPC tag with custom addressing it helps to use parameter formatting with in the parameter (ugh, I wish I could word that better)
Ex: your modbus address scheme requires you divide by 16 (or 8 or 4...) to select the appropriate 'word' or register due to how you have the modbus registers structured.
In your UDT, you might need to do something like this
s=[modbusDevice]1.HRUS{myParam / 16} --> you could end up with a tag path like: s=[modbusDevice]1.HRUS1.25
Instead do this:
s=[modbusDevice]1.HRUS{myParam / 16 | 0} --> s=[modbusDevice]1.HRUS1
I wish that parameter division/multiplication had specific floor and ceiling options but I have found that ' | 0' tends to always round down.
1 Like
Alright so it happened again and I've found this on my wireshark. Any insight? Quite new to wireshark so I'm not 100% sure what it is saying here, but seem like something wrong so it triggered the rst flag
That's the device choking on the second request in each connection. You should drill into that request detail.
(That the device breaks the connection instead of returning an error code suggests that it is a piece of [expletive]. Not surprising, for Schneider.)
Side note: you should use a capture filter to avoid large PCAP file sizes, instead of a display filter. That would also make it practical to share the file, which will be necessary if you don't figure this out on your own.
It just became good now. If I change something in the devices config such as name, timeout,.. and save it, it will do this for a period of time.
How to drill into this request, Phil?
Pick one of the packets showing in the upper half of the wireshark window that shows a Modbus Query where the next packet is the RST instead of a Response. With the query packet selected, expand its protocol details in the bottom half of the window. Look at the function code and offset and quantity of that query.
I couldn't see the function code and etc in the RST.
But with the Response, it says .000 0011 function code. I think the RST is only TCP not MODBUS/TCP
If I'm not mistaken, your screenshots that include the RST are:
- Highlighting the Modbus response &
- Highlighting the RST packet
Phil said,
Pick one of the packets [...] that shows a Modbus Query where the next packet is the RST instead of a Response. With the query packet selected, expand its protocol details in the bottom half of the window. Look at the function code and offset and quantity of that query.
If I understand correctly, Phil is suggesting you take a look at the Modbus query/request that forces the Modbus device to reset the TCP connection. If you look at it, you may be able to figure out why the PLC is choking on this request.
I think the RST is only TCP not MODBUS/TCP
Yes, RST is not a Modbus function, it's a TCP flag. It indicates the termination of the TCP connection. The same TCP connection you're sending/receiving Modbus with.
1 Like