Modbus RS485 8n1 at LabVIEW 2014

[jkirchhof@iset.uni-kassel]

Dear all,

I want to communicate with an Kaco inverter via RS485. Problem is, that the inverter only supports the mode 8N1, 8 data bits, no parity and one stop-bit. Some Modbus specifications suggest, that a Modbus message should be done in 8N2, 8E1 or 8O1, but other documents show, that also 8N1 can be used. Is there a solution for this problem, which is compatible to my old LabVIEW 2014 license?

[rolfk]

What Modbus driver library are you using? The whole thing is pretty much independent of your specific LabVIEW license or version, pretty much any will suffice. 

[RTSLVU]

The serial protocol your device uses is dependant on the device you are using. I suggest you RTFM as it will tell you what its defaut protocol is and some devices can be set to any protocol you want.

The LabVIEW Modbus API handles that in the "New Serial Master" vi.

[frada]

In the last few days I had the same problem with the MODBUS control of an Angelantoni's DY250 climate chamber which has a RS232 port with hardcoded 9600-8-N-1 settings; I used LabVIEW 2024 Q1 with:

- the new LabVIEW MODBUS API included with the Datalogging and Supervisory Control Toolset

- the old NI MODBUS Library v1.2.1.42 which can be installed as a separate package using the VI Package Manager (VIPM)

- a low-level direct implementation using VISA Serial

Both the first two implementations gave me systematic timeout errors in the reading of holding registers from the climate chamber (Error 0x38); only the third solution (the direct implementation using VISA Serial) worked perfectly; also a 4th attempt using MATLAB with its own MODBUS library worked perfectly at first attempt and without any error.

Only after a thorough debug activity I found the origin of the problem: it was due to the fact that both the LabVIEW "Create Master Instance.vi" (for the new MODBUS Library) and "Create Modbus Instance.vi" (for the old MODBUS Library) seem to set 2 stop bits for the serial RTU communication, and this setting is completely out of the user control (those VIs don't have a dedicated input for the stop bits setting). I discovered the origin of the timeout error in reading only after some hours of debugging my applications using a Serial Port Sniffer utility.

I think that NI should consider the opportunity to add this additional input to their MODBUS Serial RTU initialization VIs; IMHO it would be a common sense choice that would greatly simplify the work of users of the LabVIEW MODBUS libraries.

In the meantime a workaround exists and I found it in another post of this forum: we can use a property node of the VISA Serial resource after the initialization VI, as in the following code snippet:

At least this is the solution that work (very well) for me!