Actions
Forum Thread Details
  • Replies 29 replies
  • Subscribers 288 subscribers
  • Views 889 views
  • Users 0 members are here
Related

E14 Community recommendation for ModBus TCP client

colporteur

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

image

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.

  • in reply to shabaz

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

  • in reply to shabaz

    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:

    1. Defined Terminology: It explicitly details domain-specific terms (like coils, discrete inputs, holding registers) so a developer doesn't have to guess.

    2. Clear Structures and Mappings: It provides precise payload formats (<additional_address> <modbus_request_pdu> ...) and error/exception tables.

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




  • in reply to BigG

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

  • 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

  • in reply to colporteur

    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.

  • in reply to shabaz

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

  • in reply to shabaz

    I don't see the need at the moment to rabbit hole wireshark. If I can query the interface (i.e. a client tools) and get results, I'm out of here. TCP passes the DMZ rules I'm golden. Myopic focus, can connection pass packet pass the FW.

  • in reply to beacon_dave

    Yeah I got excited with this find. I've considered a cut and paste to see if I can get a phthon scrpt to work. Shabaz has given me a better starting point, so I will start there first if an app search is unfruitful.

  • in reply to beacon_dave

    WireShark is awesome.. just noticed there's an extension that will do Modbus-RTU too: jzhvymetal/WiresharkSerialAdapter: Wireshark Serial Adapter for Windows 

    I'm currently writing up some notes for myself regarding RTU, (will put them on GitHub) but will probably test with WireShark to confirm I've interpreted things right. 

  • in reply to shabaz
    shabaz said:
    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)

    Learn the Modbus RTU and Modbus TCP protocol in 1 hour: 
    Tools for testing Modbus (Modbus TCP View, Wireshark)

    https://www.youtube.com/watch?v=RiYHcFqbxCo&t=2006s