SnapModbus

[davenardella]

Hi All,
here to present my last work:
SnapModbus: an open-source multi-platform Modbus suite (libraries and tools).
It's not written in FreePascal but there is an Object Pascal wrapper than can greatly simplify your life, and, I suppose that someone recognized the paw print 

There are dozens of excellent libraries that implement Modbus, both free and commercial.
So, the question is: did we need any more libraries? How are they different?

The main purpose of this suite is to greatly simplify the commissioning of a Modbus system, Generally, the communication libraries focus only on the way of transferring data to and from the peripheral, limiting themselves to the syntax and showing an "educational" aspect where all the devices are homogeneous.

The reality is quite different, we often find ourselves faced with a "field" made up of various peripherals of different technology (Ethernet or serial) which have different response times and whose data need to be updated with different methods and times. The challenging work is not how to exchange data with one device, but how to exchange data with all of them efficiently.

SnapMB's goal (which I hope it has achieved) is to manage a complex field as easily and efficiently as possible. This through the abstraction of the transfer protocol (a TCP or RTU client are the same object and its behavior can be changed on the fly) and the availability of two architecture models:

- Virtual Bus: a protocol-independent half-duplex way to communicate with all devices, regardless of their technology (Ethernet or Serial).
- Fully parallel management: a multithreaded way to peer-to-peer data exchange with all devices (including RTU devices) simultaneously.

Tested in Windows, Linux, FreeBSD, macOS. 32(where available) and 64 bit.

no sponsor, no donate, no pro version to be paid.

Enjoy.
https://snapmodbus.sourceforge.io/

[af0815]

Thank you for your work. SnapModbus is indeed interesting and will span the tree from Simatik to ModBus.

THANKS

[avra]

Hello Dave,

nice work as always, with both coding and documentation 

I am so glad that you have also included ASCII and RTU over TCP/UDP.

Thanks! 

[davenardella]

Hello Dave,
I am so glad that you have also included ASCII and RTU over TCP/UDP.
Thanks! 

I'm glad you like them, since you are a connoisseur of industrial communication

[avra]

Hello Dave,
I am so glad that you have also included ASCII and RTU over TCP/UDP.
Thanks! 

I'm glad you like them, since you are a connoisseur of industrial communication

You are too kind! 

[ThomasK]

Hello Dave,

Thank you so much.
Do you have a plan to test also on a RaspBerry Pi?

I have an afterwork project were I need to simulate a PAC1661 (7KT1661) on a Pi.  This will save routing a ModBus cable from the real PAC to my Wallbox.


Best Regards,

Thomas

[af0815]

Do you have a plan to test also on a RaspBerry Pi?

Have you tried to compile the libs on a RasPi ?

Normal the projects, Dave created in the past, can you recompile to have the correct version, special under Linux. 

[sstvmaster]

Hi Thomas, i think he does test it under RasPi.

Look at: https://snapmodbus.sourceforge.io/refman.html
and scroll down a little bit to "Test platforms used"

Linux (ARM) Raspbian 32 bit    g++ 10.2.1    arm32    32 bit
Linux (ARM) Raspberry OS    g++ 10.2.1    aarch64    64 bit

[ThomasK]

Have you tried to compile the libs on a RasPi ?

Normal the projects, Dave created in the past, can you recompile to have the correct version, special under Linux.

Well I have to apologize, I was so overwhelmed - I didn't read the whole manual.
I downloaded the archive immediatly and didn't find the binaries.

Yes it did compile like a charm. Now I have to start creating a simple device for challenging my programming skills.

Next is sniffing the ModBus with the real hardware attached to find out which registers have to be transported.

Thanks to all for the hints.

Thomas

[dseligo]

Well I have to apologize, I was so overwhelmed - I didn't read the whole manual.

A friend sent me message yesterday:

6 hours of debugging can save you 5 minutes of reading documentation

[bobby100]

I've played with this lib for the last two days because I really need that RTU Server/Slave. Other FreePascal/Lazarus solutions I've tried didn't implement it at all.
I've used the demo app (WinDevice.exe) and extended it to suit my needs, but it failed on a real-life test today - many telegrams got rejected.
I've tested it with Modbus TCP too, and it fails for the same telegrams. The same telegrams are working just fine with delphi-modbus and PascalSCADA as clients. The telegrams gets rejected as "illegal function", and the Log says that these are being directed to register address 0, which isn't the case.
Writing Coils work, but writing holding registers don't etc (telegram is accepted, but there are no changes in the GUI). Reading Inputs and Holding registers fails too.
Next problem - it seems that Zero-Based register numbering isn't working at all for Device/Server.

I have a couple of PLCs ready for testing (Priva, Loytec, Beckhoff). Some of these have zero-based register numbering.
I would like to get this solved. Any pointers?

[ojz0r]

Have you used an analyzer to actually see what is being sent?

I've written modbus tcp client and server console apps as a hobby a few months ago.

[bobby100]

I didn't use an analyzer, but at least for TCP I could test it with a couple of programs, and with the other programs it is OK.

[ojz0r]

So the tcp part is not the problem, only RTU?

Could you do a loop back and check it with a serial analyzer?

[bobby100]

Both TCP and RTU have the same problem on SnapMODBUS.
I can test TCP with other apps, but I can't test RTU with other apps.

The screenshots (PLC is a Master/Client, the apps are Slave/Server):
 - PLC_config - the configuration of the Modbus registers on the PLC. Red are bit values, green are 16-bit values. The list can't be sorted, sorry for that
 - PLC_my_app - left is app that I wrote, based on delphi-modbus. Right is the HMI from PLC - everything is OK
 - PLC_SnapMODBUS - left is the demo from SnapMODBUS. Right is the HMI. The Read values in PLC are leftovers from the previous session (the last valid value remains in register)
See how many telegrams are rejected by SnapMODBUS?