Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: PLCwannabe on May 06, 2022, 12:28:42 AM
-
I need to retrieve values from a power quality meter, that is connected via ethernet to the same network as my brx Plc. I'm trying to use an MRX instruction to read the values via Modbus/TCP, but having no success. The MRX never sets success or failure bits, it seems like its locked up. When I do a program/ run transition, then the mrx error bit sets.
-
If you try to poll the monitor with another client, such as Modbus Poll from your PC, can you get it to respond? Do you get a valid read?
-
Have you tried reading "Input Registers" instead of "Holding Registers"?
-
I haven't tried much of anything yet. I'm pretty proficient now at Modbus RTU, but this is my first crack at Modbus Tcp, I was hoping that I was doing something totally wrong, like using the wrong instruction. Is it really as simple as putting the IP address of the slave device into an MRX instruction, and it's supposed to worK?
-
I haven't tried much of anything yet. I'm pretty proficient now at Modbus RTU, but this is my first crack at Modbus Tcp, I was hoping that I was doing something totally wrong, like using the wrong instruction. Is it really as simple as putting the IP address of the slave device into an MRX instruction, and it's supposed to worK?
Yes.
-
I haven't tried much of anything yet. I'm pretty proficient now at Modbus RTU, but this is my first crack at Modbus Tcp, I was hoping that I was doing something totally wrong, like using the wrong instruction. Is it really as simple as putting the IP address of the slave device into an MRX instruction, and it's supposed to worK?
In your image, the Modbus program blocks are disabled. Make sure they are running the entire time you are doing Modbus comms.
-
Those modbus blocks are for the onboard serial port communicating with a genset, which is working well.
So now I'm trying to poll another BRX Plc (IP 192.168.1.72) and that isn't working either. The MHR 1-10 on the server Plc are set to random numbers, Modbus Tcp server is enabled. Could you post a couple example rungs for the Modbus TCP Client plc, that would read MHR1-10 from the server plc?
-
Are you able to ping the modbuss address from your PC? Does the unit need to have its modbus server enabled? I had this issue with a unit that I was trying to communicate with. I had to enable the modubus server on the unit itself.
-
I noticed the device IP Address was 192.168.1.60, but the MRX is using 192.168.1.72?
Realize TCP timeouts are LONG (much longer than 1 second), so driving your MRX using ST4 is not going to do what you think it's doing if the comm is not going to "queue up" requests. If the cable is disconnected, it won't report an error for 30(?) seconds. It won't hurt anything to attempt to re-fire an MRX that is still working on a previous comm, but it's not going to do anything until it finishes the previous one.
-
I was able to get 2 BRX plc to communicate via Modbus tcp, though I had to update the client PLC OS to 2.9.3 to get it to work. Not sure why it wouldn't work with OS 2.8.6.
When trying to connect with the power quality meter now, I get Exception code 4 every time, within 1 second. What does this indicate?
-
I was able to get 2 BRX plc to communicate via Modbus tcp, though I had to update the client PLC OS to 2.9.3 to get it to work. Not sure why it wouldn't work with OS 2.8.6.
When trying to connect with the power quality meter now, I get Exception code 4 every time, within 1 second. What does this indicate?
That is a standard Modbus "device failure" exception. Don't know what would cause your device to return that. We don't every return it from our server.
Don't know specifically why you were having issues, but there were some issues with Modbus TCP on 2.8.x. They were fairly rare and generally a result of unstable networks, but if you are point to point it should just work.
-
Well, I'm not exactly point to point, as there are a few unmanaged ethernet switches, and a couple of wifi radios in the link between the plcs. However, just one ethernet switch between the Brx and the power meter device.
-
Well, I'm not exactly point to point, as there are a few unmanaged ethernet switches, and a couple of wifi radios in the link between the plcs. However, just one ethernet switch between the Brx and the power meter device.
2.9.x resolved those issues and should work work much better in unreliable networks.
The issue in 2.8.x got by us because we weren't testing in unreliable networks. We were able to easily dupe the problem, fix it, and prove we'd fixed it, once we started doing hateful things to the network infrastructure.
-
If you try to poll the monitor with another client, such as Modbus Poll from your PC, can you get it to respond? Do you get a valid read?
I downloaded Modbus Poll on my PC, and I can read 100 registers every 500Ms, with no issues, from the power meter. But still no luck with my Brx. How can I troubleshoot this further?
-
Make your PC the target for the read and using Wireshark, capture the BRXs request packets.
Also record the successful queries from when the pc is the client.
-
If you try to poll the monitor with another client, such as Modbus Poll from your PC, can you get it to respond? Do you get a valid read?
I downloaded Modbus Poll on my PC, and I can read 100 registers every 500Ms, with no issues, from the power meter. But still no luck with my Brx. How can I troubleshoot this further?
Modpoll uses 0-based addresses. Do-more uses 1-based. Make sure you are using the correct address.
-
Make your PC the target for the read and using Wireshark, capture the BRXs request packets.
Also record the successful queries from when the pc is the client.
Here are a few wireshark screen shots of my PC (192.168.1.50) successfully polling the power meter (192.168.1.60) for register 2200.
Also a couple screenshots of my BRX (192.168.1.75) polling the PC (192.168.1.50) unsuccessfully for register 2200. Hope someone can make sense of this.
-
Make your PC the target for the read and using Wireshark, capture the BRXs request packets.
Also record the successful queries from when the pc is the client.
Here are a few wireshark screen shots of my PC (192.168.1.50) successfully polling the power meter (192.168.1.60) for register 2200.
Also a couple screenshots of my BRX (192.168.1.75) polling the PC (192.168.1.50) unsuccessfully for register 2200. Hope someone can make sense of this.
Don't know why, but it's never getting to the Modbus portion of the transaction. The device is never answering the request to open the connection.
-
There isn't a Modbus slave device set up on my pc, maybe that is why the connection is never made. I just hoped that by looking at the read request from the BRX to the PC as compared to the read request from the PC to the power meter, someone could point out what the BRX is doing "wrong". Can you recommend a modbus slave simulator that I could install on my PC?
-
There isn't a Modbus slave device set up on my pc, maybe that is why the connection is never made. I just hoped that by looking at the read request from the BRX to the PC as compared to the read request from the PC to the power meter, someone could point out what the BRX is doing "wrong". Can you recommend a modbus slave simulator that I could install on my PC?
I don't see evidence that BRX is doing anything wrong. The device isn't answering, but the SYN request appears to be correct. If you want to email the captures to support@hosteng.com, we'll look closer to see if anything is obvious.
The BRX simulator works great as a Modbus slave.
-
There isn't a Modbus slave device set up on my pc, maybe that is why the connection is never made. I just hoped that by looking at the read request from the BRX to the PC as compared to the read request from the PC to the power meter, someone could point out what the BRX is doing "wrong". Can you recommend a modbus slave simulator that I could install on my PC?
Sounds more like it doesn't like incoming connections. Maybe a firewall thing? Also, the reason I suggested using your PC as a server target was so you could see the BRX request traffic. Another option is that you can spy on the real comms with the monitor in-circuit with a mirroring switch like a Netgear GS10xE. Then you can let the BRX talk to the power monitor as normal and still be able to see the conversation via Wireshark on your PC.
-
The BRX simulator works great as a Modbus slave.
That's a really slick idea -- never thought of that! :o
-
The BRX simulator works great as a Modbus slave.
That's a really slick idea -- never thought of that! :o
And it's even got a built-in scripting engine for simulating device behavior! Sorta kinda.
-
Man, is there anything it doesn't do? With that you can really do more!
-
Turns out I didn't have the device ID set correctly. When I first started this thread, I had tried setting the device ID to 1, but for whatever reason, before I updated the PLC Oss, it still didn't work. Then when I was doing the communication between the two BRX plcs, it didn't seem to matter that device ID was left at default 255, so I wrongly assumed that it never mattered with Modbus Tcp. As soon as I set ID to 1, i could read all the power meter values with the simulator, and then also with the plc.
I guess the lesson here for me is to keep it simple, and never assume anything.
-
Good catch. I think most TCP devices ignore it, but once in a while one cares. One legitimate use case for it is when you have a TCP gateway with a bunch of RTU devices on the other side. For individual devices though I don't see that if makes much sense.
-
Turns out I didn't have the device ID set correctly. When I first started this thread, I had tried setting the device ID to 1, but for whatever reason, before I updated the PLC Oss, it still didn't work. Then when I was doing the communication between the two BRX plcs, it didn't seem to matter that device ID was left at default 255, so I wrongly assumed that it never mattered with Modbus Tcp. As soon as I set ID to 1, i could read all the power meter values with the simulator, and then also with the plc.
I guess the lesson here for me is to keep it simple, and never assume anything.
Which ID did you set to 1? The one in the MRX/MWX instruction and/or the one in the power meter? Regardless, I'm wondering why the other clients worked?
-
The power meter by default is 1. The MRX had to have the id set to 1 as well. This meter also has terminals for a serial Modbus connection, maybe that has something to do with it.
The Modbus Poll software default slave id is also 1, that is why it worked right away.
-
The ID is generally unused in Modbus/TCP. When used, it generally addresses sub-devices, like through a gateway.