NI LabVIEW Modbus API Discussion

[Porter]

You could try the Plasmionique Modbus Master library. It handles the transaction ID differently, allowing for TCP packets to be received out of order without causing an error.

Plasmionique Modbus Master Toolkit for LabVIEW - Download - VIPM by JKI

[Tomwell17]

Hello, 

I wanted to give a quick update on some of the Modbus communication that I was doing previously. 

With the help from ShivamSaxena, I transitioned into a case structure-based data collection loop. This helped me keep distinct states during the process of data collection separate and allowed me to debug knowing what part of the case I was erroring at. I also made some changes to the way that the program samples with the advice about the wait time as well. You can see the new structure below:

If you notice the modbus master on the left side, I changed my communication to serial. Previously, I had been wiring the weather station to an RS-485 to ethernet converter and trying to do TCP protocol for the data collection. This was giving me a headache with the error 56 and I cold not figure out if it was failing at the weather station, ethernet converter, or the LabVIEW script. I ended up adding in a local router between the converter and my laptop to see if that helped, tried another ethernet converter from a different manufacturer, and even tried different computers. Nothing resolved this so I bought a serial converter and have had no problems since this transition! I am far from an expert at Modbus communication but the amount of time I put into debugging the TCP master was an issue. Maybe this will help someone in the future so I decided to post some updates.

Thanks for the help from the forum!

[jaskulskib]

Hi All,

Wanted to see if somebody could help me understand how to utilize the Modbus RTU protocol with a DAQ, I haven't ever gotten into it before so it's very new to me 🙂

 I am using a DGH D8200 DAQ unit with a pressure transducer in a 4-20 mA loop. I have been able to get a successful setup within DASYLab, but would like to transition to LabVIEW instead.

I have gotten to a point where I can establish some sort of connection with the DAQ, the VI is not giving me errors. However, I am only getting a value of 0 out of the channel. I'm trying to configure it in the same manner that I did on DASYlab, but seem to be either missing or not seeing where to establish some points.

Here is what my configuration for the DAQ is on DASYLab:

As for my VI, I have kept it simple, only to read inputs registers and show the values. This VI is from an example that DGH provided, but featured outdated modbus functions:

[Mac_0313]

Hi,Mark,
I also encountered error 539193 when using Modbus/TCP. Error 538193 popped up a few minutes after I connected the device to communicate. Could you give me some solutions to this problem?

[Nico_W]

Hello all,

I am using the library to connect a PLC Modbus master through TCP, which dims LED drivers over different protocols.

Everything runs fine, but I split all my dedicated functions in separated VI's and I would like to build these separated VI's in DLL by means of the application builder add-on.

Unfortunately, it shows an error when I am trying to selected the considered VI's, as they contains Labview classes terminals (see the attachment).

A main VI executing all these separated functions runs well in the builder.

Do you see another solution, please?

Thanks and kind regards,

Nicolas

[carlos_camargo]

This question is more about using the application builder.  You should ask your question in a forum or thread dedicated to that, but it's been a while so maybe you've resolved it already.  My guess is that you have to build the whole class into the DLL rather than just isolated functions.

[Nico_W]

Hi Carlos,

Thanks for your answer. All my apologies, I did not find the dedicated applicaiton builder forum.

I finally solved the issue by exporting the VIs as .NET interop assembly.

[beuvink]

Open source LabVIEW. And now??

Just reaching out to any LabVIEW developer in my network. NI has open sourced the modbus library. Works great.. but... (of course there is a but)...

I have devices that have registers that are not 16-bit, so I have to make modifications. When I look at the repo, it has seen no changes in 7 years. The readme file just contains so placeholder text and the most active fork doesn't seem to have that much documented changes. And there isn't a single one with pull request.

Does anyone have experience starting to work on making changes in a way that the community can benifit.

The approach that seems likely to me would be:

- Install with VIPM, see where stuff should be placed

- Fork into own account, with good commit messages and updated readme

- Remove with VIPM to get open source version, store at same location

- Start work in new branch (in my own copy) and when done make a pull-request (and hope someone is still listening)

Or are there better ways to proceed?

https://www.vipm.io/package/ni_lib_modbus_library/?utm_source=vipm_desktop

https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

https://forums.ni.com/t5/NI-Labs-Discussions/NI-LabVIEW-Modbus-API-Discussion/td-p/3373078/page/53