Modbus...

[MPCC]

While playing around with the Modbus module, we noticed a couple of things.

1. It is using a non-deterministic Modbus driver and it places it synchronously in the loop.

"It is also not designed to execute on LabVIEW Real-time run-times."

From this article: http://www.ni.com/example/29756/en/

* I forked the module and put the read-writes into a daemon so that dataflow can still be synchronous but IO is not. The ability to not block the loop but still be synchronous may not be a hard requirement for everyone. In our case, we needed to format output data before sending it to the module and format input data after getting it from the module.

I don't think that this is necessarily a bug but it would be nice to have daemonizing the IO in the core module. (The reason that the 'run async' button doesn't work in this case is the need to synchronize with our data modification modules before and after the i/o and without introducing cycle delays.) 

2. The modbus module conforms to standard IEEE standards for register codes and addresses. We are trying to connect to devices that do not conform to these standards because... Modbus device manufacturers do whatever they want. Because of this we, are investigating swapping out the driver for another, driver assuming we can find one that gives us the flexibility that we need. 

If you have any advice on this endeavor, please send it my way. 🙂

Posting here instead of github because I believe this to be a discussion about decisions rather than a bug or direct feature request.

Thanks!

michael

[MPCC]

Upon further inspection, it appears that the module that we are using does conform to the NI document here: 
http://www.ni.com/white-paper/7675/en/

However, the driver that is used in the modbus module has the Read Input Register and Read Holding Register's reversed. This appears to be a bug with the modbus driver and not with the DCAF Module.

[BeCeGa]

Hi Michael,

You are correct regarding number 1:

We should move the inputs and outputs to a different process. For slave it doesn't mater because it is already a daemon, but it is doing TCP reads and writes and this should be done.  I just opened an issue for this:

https://github.com/LabVIEW-DCAF/ModbusModules/issues/34

 Regarding the 2. We just cover the standard and we don’t plan to go out of it as we will never be able to cover all Modbus variants.  One of the improvements we are working on is allowing to change the order of the words for multi byte type of data as that is no covered in the standard.

 About the Modbus library do you mean we are just have the Vis swapped input registers and holding registers, is this as a master or a slave?  What is the issue that you are seeing?

The other alternatives to the library are the Modbus library included with LabVIEW, which should work the same way, and there is the Plasmionique Modbus library (https://lavag.org/files/file/286-plasmionique-modbus-master/).

Best Regards