Some question about the Modbus library

[alanturing]

Dear all,

I have some questions about the Modbus library I hope you can answer

1) Why there are two versions of the library (one with the yellow header, the other with the blue header)?

2) Which one NI does recommend to use?

3) Why NI packages one library with the base package and the another Modbus library is separately installable?

4) Why there are no methods to read the timeouts of a connection?

4) Why the property node operator can be used to set the timeouts but not to read them?

Sincerely,

[RavensFan]

---

@alanturing wrote:

Dear all,

I have some questions about the Modbus library I hope you can answer

1) Why there are two versions of the library (one with the yellow header, the other with the blue header)?

Actually there are 3.  The oldest has no header, but just a white background.  That was never officially supported by NI.  But is the one that I started with in LabVIEW and works pretty well.  I like it because you can open up all the VI's and see how the protocol works..

I don't know about a blue header, but here is one with purple header.  NI felt the need to upgrade the libraries over time.  This one is based on object oriented programming.  I think they felt Modbus libraries were important enough to build in to LabVIEW.  I believe with this object-based version it would allow you to set up multiple modbus masters or slaves on the same PC that talked through different serial or TCP ports.  I haven't fully explored that.

The one with a yellow header  I believe installs with the DSC module.  It looks like it uses the purple header Modbus VI's as subVI's.  The yellow header ones have been available longer than the purple header ones have been publicly available.   They probably still exist on the palettes to support any older projects that were built on these prior to the purple header library being made available.  I don't know if there are any advantages of the yellow over the purple.  There is an advantage to the DSC module as a whole because it allows you to create Modbus I/O servers as part of a project so that you don't need to lay down any Modbus VI's or wires.

2) Which one NI does recommend to use?

Officially, I don't know.  I would say purple over white. perhaps yellow over purple, but like I said above, I believe that is more for legacy support for people who originally started with using the DSC module.  I'm still partial to the white library.  I'm using the purple more often now with new projects.  I've never used the yellow.

3) Why NI packages one library with the base package and the another Modbus library is separately installable?

See #1.

4) Why there are no methods to read the timeouts of a connection?

 5) Why the property node operator can be used to set the timeouts but not to read them?

Because why would you need to?  You can just set them to whatever value you need them to be then you would know the timeout.  Are you talking TCP/IP or serial?  I know with serial, if you have the purple wire available, you can drop a property node on it to read the timeout value.

Sincerely,

---

[playerm1]

To add to the above, the yellow MODBUS library is installed and usable when using a licensed version of the Datalogging and Supervisory Control (DSC) Module --OR-- the Real-Time Module.

[alanturing]

Dear RavensFan,

thank you for your reply.

Regarding point 2) let's hope somebody from NI takes care to answer.

Regarding points 1) e 3) I had compatibility problems migrating projects with LV2015. I checked now with LV2017SP1 and I think they reorganized things better: the yellow ones are methods of the Modbus Master.lvclass which inherits from the Modbus API.lvclass. I think Modbus API is intended to be an interface while the Modbus Master.lvclass is the concrete implementation. Probably the VIs with yellow headers are those of interest for the majority of the users (who don't need to extend the Modbus protocol).

Regarding points 4) and 5) the thing is that I have a pool (array) of Modbus connections configured with different timeouts. When the server drops the connection (probably a malfunction on their side) I need to close and reopen it. It would be very handy to re-open the connection with the same parameters.

I don't want to implement a connection object storing this information in my application on legacy code (and by the way it is quite stupid anyway because the information is already stored in the Modbus master class). I could easily extend the Modbus Master.lvclass myself, but I think this should go straight into the next LV update.

Sincerely,

[alanturing]

Hello and thank you for the info.

Do you know which one comes with the base package (ONLY LabView)?

Sincerely,

[RavensFan · Accepted solution]

The purple header ones.  I don't know which version of LabVIEW added them in.  I feel it was at least 5 years ago.  I would recommend using the purple since you won't have to worry about the licensing of using the yellow based ones.

You might want to suggest your idea on the LabVIEW Idea Exchange.

I'm not an OOP person, so I don't know what all the recommended practices are.  But it would make sense to me that for any project, any properties that are settable by the using the API should also be readable using it.

[playerm1]

I don't think any of them come with the base package of the LabVIEW IDE.  The "white" and "purple" versions referenced in the other posts are open source addons that need to be installed either manually or using VI Package Manager.  Personally, I have used the "purple" object-oriented version successfully in the recent past.

Take a look at these links:

https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Modbus-API/ta-p/3524019

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

[RavensFan]

You're right.

The purple library I installed via JKI Package Manager.  It is called NI Modbus Library.  Distributed by NI on the NI LabVIEW Tools Network.