Modbus change variable between virtual devices

[a.alvsantos]

Hi,
We are using Revolution Pi on a product we have in our company. The device uses two virtual devices (both Modbus TCP slave) and read approx 15 registers on each device. Each device are very similar between them. We experienced a problem that RevPi swap register and variable between devices. Example of the problem experienced:
Time 0 (Correct Behaviour)
- Device 1:
Register 40000 reports 115000
Variable Name: Bus_Rectifier_Voltage reports 115000
- Device 2:
Register 40000 reports 4805
Variable Name: Bus_Converter_Voltage reports 4805

Time 1 (Bug Behaviour)
- Device 1:
Register 40000 reports 4805
Variable Name: Bus_Rectifier_Voltage reports 4805
- Device 2:
Register 40000 reports 4805
Variable Name: Bus_Converter_Voltage reports 4805

Please see attached photo. After several minutes/hours or after a reboot the normal/correct behaviour gets restablished. Can you please advise/assist?

Thank you,
Regards,
Alex

[a.alvsantos]

We have already experienced this behaviour twice without any reasonable explanation and without being able to replicate the issue. In our configurantion we have 5 virtual devices. Two of these devices have very similiar Modbus register map. We are pooling registers at 1000ms. For twice we have seen RevPi having reporting a strange behavour. Out of the blue the values of the registers of a given group from device 2 (several variables impacted) started to take the values of the same modbus register of device 1. As for device 1 the values reading are consistent with the modbus register. This episode happen while the system was running for several hours without any modification. Once it happen we restarted modbus-master.service and it became normal again. Any advise?

Thank you,

[KTB-Vo2345]

Looks like there might a bug in the modbus communication of the pimodbus master software.
We tried to get in touch with Kunbus Support to get this problem solved, but there is zero response for this problem.

This is our posting (in German)
It took a month to get a response in the form of a question.
viewtopic.php?p=10604&sid=2963bdcda14fa ... 077#p10604

Would be very nice to hear Kunbus's opinion

@a.alvsantos

We started examinating the TCP traffic behind the pimodbus master - here you can see e.g. that the tcp-stream is not consistence and that let conclude the software is not reacting properly.
Maybe this might help you to identify your problem.

Best regards
KTB

[a.alvsantos]

Hi @KTB-Vo2345,
Thank you for your reply and having raised the issue to our attention. We have carried further tests and do not find any reason for these swaps. In addition to this we are also experienced that some relays (controlled via Modbus) change state without any reason and in a random way. Have you been able to some how replicate or understand when it happens?

Thanks in advance,
Alexandre

[saardrimer]

I'm also looking forward to KUNBUS addressing this issue soon. I'm currently working on a project with two MODBUS devices and am concerned about this issue.

[a.alvsantos]

Hi @saardrimer,
Thanks for raising attention of KUNBUS to this topic. Have you experienced similar issues?

I'm also looking forward to KUNBUS addressing this issue soon. I'm currently working on a project with two MODBUS devices and am concerned about this issue.

Thanks
Alexandre

[dirk]

Hello everybody and thank you for your patience. We could reproduce the bug at our side with irregularities in multiple instances of Modbus TCP Master input register values

The corresponding Modbus action status register value reports value 0 (i.e Error Free) and no piModbusMaster erro

logs either occur at such instances.This may therefore require deeper investigation inorder to come of with a fix

Meanwhile a possibility of directly using the libmodbus API for Modbus TCP application bypassing pictory virtual modbus could be explored.
https://libmodbus.org/documentation/

[saardrimer]

Hi Dirk

It's great that you managed to replicate the bug and hopefully working on a fix.

> This may therefore require deeper investigation inorder to come of with a fix

The Modbus functionality is one of the main reasons why we've chosen your platform, so I feel that sending us to sort ourselves out with the libmodbus docs is somewhat of a disappointing response. Now that you've identified the problem, I'd appreciate knowing what's your plan for a fix/workaround including an estimated timeframe (days, weeks, months, never?).

I'm currently developing the code (in Python) for the Modbus and your response will affect how go about it, and our evaluation if the RevPi is the right solution for our application.

Thanks,
Saar.

[KTB-Vo2345]

Hi Dirk,

thank you for investigating into this error.

Same here for us: actually we plan to use the RevPi Compact in our pilot-series of our product - even because of Kunbus is advertising the Modbus capability.
Today we already developed our own Modbus-Data services, which is capable to manage several Modbus-Slaves at once, but we relied on the Kunbus implementation hence we are looking forward to use the PiControl for IO-control at anytime (not only for the onboard IOs of the Kunbus Compact)

Maybe Kunbus is ready to publish the pimodbusmaster.service source code as you already mention somehow in the past.
We can think of, to contribute to this project, maybe with trouble shooting or external code review.

Best regards

[Simvei001]

Hi,
is it possible to get access to the source code of the pimodbus-master service?
I had found another blog post in which it was stated that the software is not yet released, but it is in progress.

I would like to look further into the problem and compare the ideas to a self-implemented version of the Modbus communication.
If the software should not be open source (as many other Revvolution Pi software is...), it would be sufficient to get (reporter) access to a private gitHub repository to review and discuss the code.

I am looking forward to an answer and further investigation on this topic.
Regards
Simon

Simvei001