E14 Community recommendation for ModBus TCP client

Hi Sean,

While it's not the best protocol for this (it's a bit "naked"! and the cloud app vendor ought to have come up with better proposals to be honest), but anyway, I was interested, because by coincidence I'm just getting going with Modbus RTU currently (RS-485 instead of TCP, some differences in the protocol). I got curious enough to try to find the user manual for the 1280 Modbus TCP card. I gave that to AI, and it generated the Python code attached below. It complained that the user manual was vague in places, which it is, so I told it to try to make a simulator that accepted a few different function codes, and then try to simulate the cloud side too). 

The screenshot shows the 1280_simulator.py file running at the left side, it just sits and waits for a connection.

On the right window, you can see the cloud_app_simulator.py file running, it makes a TCP connection to the 1280 simulator, and then tries a few function codes.

Currently the code transmits to port 127.0.0.1 and port 1502, you'd need to modify both of those to suit your needs.

Please don't ask me for modifications or tweaks, I don't know Modbus TCP nor what the AI did! : ) It might be ok but it might not. It might completely fail.

I suppose one other thing worth doing is perhaps running WireShark, and examining if it successfully decodes whatever is sent by these two simulators. I didn't try that (I've not got WireShark installed currently). I only tried running the Python code on Windows, it should work with Linux but I can't be sure.

modbus_tcp_python.zip

I've used your client side program. It appears to connect but generates errors.client_output.zip

Hi Sean,

Your output is successful. Here is what you'd see if there was no TCP connection at all:

And this is what would be seen if the TCP connect occurred, but there was no response data from the 1280 end; it would just hang on Step 1 of the first test case (which has three steps):

However in your client_output file, I see this, so it got past step 1 (and 2 and 3) and all of the first test case was successful.

Your log file stops on the second test case step 1. I'm guessing you've got the real 1280 device attached, and it simply doesn't like the second test case (which is fine, since the test cases were written based on the ambiguous user guide, so the second test case happens to attempt a register that the real 1280 doesn't like. The log file shows that second test case was using a read register # 40257, that's the only difference from the first test case. So, since it's now confirmed your real 1280 doesn't use 40257, that could be deleted from the list inside the cloud_app_simulator.py file if you wished. But it's already confirmed that the 1280 end did respond with TCP data during the first test case.

Hi Sean,

Your output is successful. Here is what you'd see if there was no TCP connection at all:

And this is what would be seen if the TCP connect occurred, but there was no response data from the 1280 end; it would just hang on Step 1 of the first test case (which has three steps):

However in your client_output file, I see this, so it got past step 1 (and 2 and 3) and all of the first test case was successful.

Your log file stops on the second test case step 1. I'm guessing you've got the real 1280 device attached, and it simply doesn't like the second test case (which is fine, since the test cases were written based on the ambiguous user guide, so the second test case happens to attempt a register that the real 1280 doesn't like. The log file shows that second test case was using a read register # 40257, that's the only difference from the first test case. So, since it's now confirmed your real 1280 doesn't use 40257, that could be deleted from the list inside the cloud_app_simulator.py file if you wished. But it's already confirmed that the 1280 end did respond with TCP data during the first test case.