Forum - Recent Threads

E14 Community recommendation for ModBus TCP client

colporteur — Thu, 11 Jun 2026 21:20:08 GMT

I am looking for an application to query a ModBus TCP interface on a scale head?

The company I am working for has recently installed a RiceLake 1280 scale indicator with a Modbus TCP interface. The scale indicator is IP capable and resides in a network DMZ. The goal is to have a cloud vendor pull scale data over the network from the Modbus interface. I'm looking for an application that can query the Modbus interface to confirm communication with the interface.

The scale vendor recommended an application in order to set the Modbus TCP interface IP address. I managed to get that working, proving the interface IP answers an IP ping. DMZ rules have been set in place to isolate the indicator. I want to test that the cloud vendor can get to the Modbus interface and pull the data. I'm thinking maybe there is a software tool like minicom is for serial communication, except the tool is for Modbus.

E14 has some great Modbus resources but nothing to match my search. A Modbus client query tool. I'm hoping there is a community member that has experience with Modbus TCP and that they could recommend application software to perform the task.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Mon, 05 Oct 2026 16:54:14 GMT

Screen is touch, that is about the extent of my knowledge.

It has network capabilities but we currently are not using it. The objective is to extract the scale data and move it to our ERP system.

RE: E14 Community recommendation for ModBus TCP client

SensoredHacker0 — Mon, 05 Oct 2026 13:11:36 GMT

oh its an embeded linux web server with IO!
maybe ill see one cheap on ebay and really have at the thing
at 4K$ new, ain no way.

RE: E14 Community recommendation for ModBus TCP client

SensoredHacker0 — Mon, 05 Oct 2026 12:59:47 GMT

I'll necro post.
pymodbus tcp typically does fine.
My boss showed me another library recently that seems to work well... bu t I forgot what it is called.
typicaly, I start with a register map, then build out functions from there. dealing with modbus kinda sucks.
I typicaly build lists, or arrays, while my co-workers seem to like json files. thats a design choice, I favor application development,
where they favor web development, though either could work.

A specific application? lol IDK about that, I would just write it.

out of curiosity, its that a touch screen? is button IO writable?
can you push (load) different screens remotely?
what is the display graphics programed in?
are there other interfaces for programing the display?

RE: E14 Community recommendation for ModBus TCP client

colporteur — Wed, 30 Sep 2026 20:32:28 GMT

Sorry folks I am not necroposting. I recently found a Modbus resource tool that would have been ideal in this project. Command line console for modbus. I can try and remember it for the next time or put it in a place I do remember.

https://github.com/utilsec/Modbus-Swiss-Army-Knife

The name of the link should tell it all. I tried it with my scale project and discovered that via packet sniffing, it does a lot of communication when it first fires up.

If the end point is missing (i.e. typed in wrong IP) the software doesn't start. If there is a modbus device a text screen appears.

RE: Mis-using RS-485 interfaces to generate audio and visual alerts : )

kmikemoo — Sun, 30 Aug 2026 16:51:40 GMT

shabaz Sounds pretty clever to me. Simple is hard. Well done. ☺👍

Mis-using RS-485 interfaces to generate audio and visual alerts : )

shabaz — Thu, 27 Aug 2026 20:58:31 GMT

I did a bit of a hack today : )

I have a Pi Pico, attached to an RS-485 transceiver. As you're maybe aware, the RS-485 transceiver converts the UART signal into two signals, called A and B, or Non-Inverting and Inverting. The oscilloscope trace below explains this.

What's not shown is that the A and B outputs are often only enabled if requested to do so by applying a logic high on a Driver Enable (DE) pin. If the DE pin is low, then the A and B signals will no longer output a signal.

I had a request from a friend to control an LED and a little audio tone beeper from the Pi Pico. Sometimes he wanted just the LED to light, sometimes just the beeper, and sometimes both. He doesn't need RS-485.

I initially considered opening up the device and wiring things up to spare GPIO pins internally. However, after thinking some more, I realized I could just repurpose the RS-485 connections, as shown in the video:

[View:/cfs-file/__key/communityserver-discussions-components-files/148/20260827_5F00_211338.mp4:640:360]

To get this to work, all I needed to do was a software mod, to change the Pi Pico UART Tx pin to become a normal GPIO configured as an output. Then, the logic was simple:

Driver Enable (DE)	UART TXD	RS-485 A,B
1	0	Low, High
1	1	High, Low
0	0	HiZ, HiZ
0	1	HiZ, HiZ

I wired the little beeper to the A connection, and the LED to the B connection (use series diodes and resistors as required to reduce the voltage or current if needed), with the other end of each connected to 0V (ground).

I cannot turn on both the LED and the beeper simultaneously, but that's not a big deal, the code can just alternate every second as shown in the video.

I'll encase this in moldable plastic (PolyDoh), that will be good enough for the particular use-case.

Not a very clever hack, but it did save me some effort!

Thanks for reading.

RE: Mis-using RS-485 interfaces to generate audio and visual alerts : )

DAB — Sat, 29 Aug 2026 18:49:31 GMT

Good hack.

RE: Mis-using RS-485 interfaces to generate audio and visual alerts : )

Qbit — Fri, 28 Aug 2026 14:44:56 GMT

Clever hack! Using Driver Enable alongside the TX pin to leverage the high-impedance state is a really smart way to independent-control two loads without needing to tear open the enclosure.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Wed, 24 Jun 2026 21:58:36 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

BigG — Sat, 20 Jun 2026 19:34:55 GMT

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

RE: E14 Community recommendation for ModBus TCP client

colporteur — Sat, 20 Jun 2026 14:39:13 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

shabaz — Fri, 19 Jun 2026 16:03:20 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Fri, 19 Jun 2026 15:35:13 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Fri, 19 Jun 2026 15:22:20 GMT

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

RE: E14 Community recommendation for ModBus TCP client

shabaz — Thu, 18 Jun 2026 15:49:31 GMT

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).

RE: E14 Community recommendation for ModBus TCP client

beacon_dave — Thu, 18 Jun 2026 15:23:01 GMT

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

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

RE: E14 Community recommendation for ModBus TCP client

shabaz — Thu, 18 Jun 2026 15:22:05 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Thu, 18 Jun 2026 15:17:07 GMT

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.

RE: E14 Community recommendation for ModBus TCP client

colporteur — Thu, 18 Jun 2026 13:49:47 GMT

I've used your client side program. It appears to connect but generates errors.community.element14.com/.../client_5F00_output.zip

RE: E14 Community recommendation for ModBus TCP client

BigG — Sat, 13 Jun 2026 16:57:32 GMT

A slight deviation/distraction but I wondered if the page you shared would make for a Github project (something I'm exploring at present). So, I opened up the question to Gemini...

The file you linked is an excellent core element of a project because it has:

Defined Terminology: It explicitly details domain-specific terms (like coils, discrete inputs, holding registers) so a developer doesn't have to guess.
Clear Structures and Mappings: It provides precise payload formats (<additional_address> <modbus_request_pdu> ...) and error/exception tables.
Actionable Utility: A developer trying to write a Modbus communication driver in Python, C, or Go can look directly at this markdown file and know exactly how to structure their bytes.

An ideal GitHub project is simply a centralized workspace that solves a specific technical problem or serves a clear purpose for its target audience. It can be pure code, pure documentation, or a mixture of both.

RE: E14 Community recommendation for ModBus TCP client

shabaz — Sat, 13 Jun 2026 14:23:03 GMT

I'm doing a similar thing.. I'm getting AI to help me with my notes, since the Wikipedia pages (and other resources) have info scattered, and I just wanted it condensed. This is a work-in-progress, I still need to check, and will test with my real device, and capture some traffic and so on: modbus_tools/modbus_rtu_format.md at main · shabaz123/modbus_tools (but please don't use this yet, since I'm still learning!).

In some ways sometimes it's better coming at things from a beginner perspective when writing notes, because then one learns what's unclear in existing online documentation, and those are the areas I like to focus on, because it's almost guaranteed I will eventually forget again and so I will want to re-read quickly.

I got AI to write me the software for the checksum (CRC) that RTU uses (TCP doesn't require it), verified it on Windows with real examples, and will also build it on a Pi Pico to double-check (there's no endianness issue, but I still want to test on at least one microcontroller).

RE: E14 Community recommendation for ModBus TCP client

BigG — Sat, 13 Jun 2026 14:07:13 GMT

Having never done this, I was curious. So, decided to ask my AI assistant as this is how I am now learning these days. You learn by doing. The benefit with this method is that it pays to be wrong and AI is great at doing that. It simply sets a direction and off you go. Maybe this is helpful...

gemini.google.com/.../9aba1ba75b87

RE: E14 Community recommendation for ModBus TCP client

shabaz — Sat, 13 Jun 2026 13:47:30 GMT

Hi! Might depend on what the cloud app vendor can do. Depending on what they're using (e.g. PaaS) they might not have as much flexibility to confirm if things are working at that low level (i.e. TCP socket). Hence to preempt that, if the test included a higher level (i.e. valid Modbus TCP messages) then that may be quicker for them to be confident the comms is working fine, even though the Modbus TCP messages can be garbage (valid garbage). If the cloud app vendor can work at a low-level in the stack then you're right, just a TCP level check might be sufficient.

RE: E14 Community recommendation for ModBus TCP client

shabaz — Sat, 13 Jun 2026 13:32:29 GMT

Here's a video of the Python code in case it's needed to see how to run it..

https://youtu.be/1O3W2kOLMrQ