E14 Community recommendation for ModBus TCP client

I will close this post by first saying thank you for your input. Sounding out the problem and getting suggestions was helpful in arriving at the solution.

I culled a link for oceancontrol windows GUI client from the link  beacon_dave provided.   shabaz python client established a connection, I just didn't invest in generating a query. It did confirm it was working. BigG  input reminded me of net cat a network test tool I had used many moon ago. I confess net cat was the one I used the most.

Since I was only looking to confirm a connection through the firewall, net cats ease of use made it ideal for quick testing. Supported on windows and linux was bonus. I had to learn the syntax for Windows:( It is not the same as linux.

With a confirmed modbus tcp interface available it is off to configure and test a VPN end to end solution that will connect the company and vendor. Thanks again for you input. 

Ah fantastic. Not that I would know (noob here). Apparently with netcat, you can transmit the structured Modbus application bytes and see if the hardware replies. This completely validates both the firewall rules and the device's availability in one go.

Searching online brought up this page: stackoverflow.com/.../send-modbus-rtu-request-via-tcp-with-netcat-and-catch-the-response

I completely forgot about CLI netcat! I recall you can setup a transmit and receiving end on ports you are examining.

Man I miss tech coffee breaks. All those minds in one place was a great technical pool of knowledge.

I cannot take the credit, AI wrote that code, I merely pointed it at the 1280 user manual, and it spit out Python code, I merely ran it and told it of any errors, so it could correct it. The screenshot below shows what I asked it originally. It's not perfect as you noticed, since it could have provided more helpful output or automatically abort a test rather than hang.

Regarding the TCP connection etc., I'm very familiar with that part only because I ended up developing some products that heavily relied on network features/functions, I believe I would struggle with a lot of it if I had to learn it on my own.

I'm humbled by your knowledge and thankful that you are willing to share.

Many eons ago, when my skins had less wrinkles, I recall training with a senior aviation electronics technician in a course. He took the the time to share his experience. The stuff I learned in that short interaction I have never forgot. 

I can't comprehend how you extracted the information from the manual that enabled you to write code and decode the output for the modbus tcp interface. I'm envious.

I recall listening to a lecturer speaking Russian. I figured if I listened hard enough I would understand Russian. Never understood a word! I have combed the manual and reviewed your code thinking if I try hard enough I will gain the knowledge. It is not working.

If I was forty years younger, I would invest the time. I accomplished the goal. Just have the test the firewall rules set and be done. Thanks again.

I tried you trick of connecting to an IP that didn't support modbus tcp and noted the error. I suspected your code was working. Great work on a first attempt.

I believe the video is where I found the bread crumbs to the site.

Here is how the 1280 did in fact respond during the first test case:

Your log file indicates the 1280 returned a status code 269 which in hex would be 0x010d or 0000 0001 0000 1101 in binary.

According to the user guide, that means:

No error,
tare not entered, 
center of zero,
weight OK,
standstill, primary units, tare not acquired, gross weight,
first channel (I don't know if that means channel 0 or channel 1).

Anyway, perhaps this is now too much detail, since it's already clear the TCP connection to the 1280 did successfully, and that's all you requested. However, the test case shows that the actual Modbus TCP protocol layer is successfully being received and sent by the 1280 (from experience/being burnt with various protocols, I wanted the simulation to include Modbus TCP; there are plenty of situations where a TCP connect alone is simply insufficient to be sure that the next layer will pass).

FYI that Ocean Controls tool was one of the ones demonstrated in the video link I posted previously.

https://youtu.be/RiYHcFqbxCo?t=1946

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.

An update on the goal of finding a modbus TCP client.

My attempt with Shabaz offering wasn't successful so I moved onto hits from a google search for modbus tcp client.

oceancontrols has such a beast for Windows. https://oceancontrols.com.au/software-modbusview-tcp-ocs-011.html The free software timeout every 15 minutes. Once restarted you have to setup communication. I installed the software in a Windows sandbox to test.

I believe it is important to provide a return on investment. Your responses are valuable here is a return.

I don't know Modbus protocol and I am not in the market to learn it. My goal was to find software that I could use to test the ability to connect to a modbus tcp interface through the firewall to the DMZ.

The oceancontrol software is easy to install from their download.

The Configure tab (Ellipse A) is where you set the IP address of the device you want to connect to. There is no ability to save this in the free software therefore every 15minutes you have to start over.

Pressing the Start Polling button generates Status window messages and the poll window changes to Active.

Under the Communication tab you bring up a log or monitor window. The top half of the monitor window transmit screen, shows polling numbers and the bottom half polling response numbers (Ellipse B) poll 36 gives a return of poll 36. There is a polling number receive for every transmit. 

A quick cmd window netstat -an shows a connection established (Ellipse C) to the IP address and port of the interface. When polling is stopped this connection disappears. YES! We are connecting and communicating to the modbus tcp interface.

I was unsuccessful when I tried using the registers to write and read. It would be nice to interact, request a read of the scale head and see some data but that is not necessary to reach my goal.  I have little programming knowledge so I abandoned that exercise. 

For this test the modbus tcp interface was outside the DMZ. Next step is to reposition the interface inside and start testing communication into the DMZ.