LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Rewrite MODBUS library

Status: New

According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.


This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.

Trusted Enthusiast
Trusted Enthusiast

Any experiences with ModBusVIEW (serial and TCP) from SAPHIR ?


Seems very interesting and powerful but I have never used it... mainly because it is not free.

Active Participant

Hello JB,

As the product manager of SAPHIR I greatly appreciate you mention our toolkits in your comment. Hope you understand I won't going to kudo your idea 😉 but encourage people to test and use our add-ons.

About the commercialization of our add-ons, I understand this could be a concern for people and I'd like to explain why it's not free. Since 1989, the main activity of SAPHIR is to develop and integrate acquisition signal processing solutions for our customers. SAPHIR add-ons are the result of real world needs, but remain a small part of our business. ModBusVIEW first release was in 1994, since then, we have been enhancing and testing it for every new version of LabVIEW. We do our best to provide more than a set of VIs (for example you can easily test communication without writting code or have a simulated slave/server to help you in your development). At last, we have improve our organisation to provide a better support to all of our customers and we hope to be provide it at least for the 20 next years 🙂

All these work done on these add-ons represent many developper (experienced one) hours. Having customers for these add-ons help us to continue the support of them.


I take the opportunity of your idea to tell people that we continuously listen for feedback from users to improve our tools. Feel free to add your comments here or if you prefer to contact us directly, use this e-mail :


Regards and happy wiring for everyone.


Wovalab | Certified LabVIEW Architect | DQMH Trusted Advisor |
Active Participant

We are just trying to make LabVIEW talk to an instrument using MODBUS. Right now, we don't want to spend money because it's just a test, then we are using the free library. I agree with JB, but NI should keep the distance to the Sphir's package. Later a user of the free library may need more power, then is when Saphir's library may fit. Actually is a free advertisement to Saphir's product.


Keep it update is necessary Like the idea of having it among the other drivers. Kudos!

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Active Participant

I have a bad feeling that I'm stepping into some controversy, but... here it goes.


Several years ago I cleaned up the old Modbus library:


I didn't change much of the underlying code, though I did make a couple of minor tweaks to improve functionality.  Mostly I just ditched the llb, cleaned up the code, made things typedefs and commented as much as I could.  (This took me several hours -- the stock code is not pretty.)  Sorry, I'd share my version, but my company technically owns the code.


My point is that the library itself has worked flawlessly for us for several years, it's just sloppy and not well documented as offered.  I literally use the TCP version of this code day in and day out without any problem.  I use the RS-485 version quite a bit, but not as much as the TCP.  Again, I can't recall any functional issues with the code itself.  (issues with RS-485 hardware, certainly.)  I will also add the disclaimer that I have only used the driver for Modbus master functionality, not implementing a Modbus slave.


In the event that NI decide not to follow your idea, this option has worked reasonably well for me.


I would definitely vote for NI releasing an "official" version that doesn't involve shared variables, though.  I'm all for keeping things simple.  (i.e. forgoing extra layers like shared variables)  Just my opinion.


I will Kudo this idea.




If the existing library could be fixed and re-posted by NI it would be a good stop-gap measure. I also agree with the comments on the ModBus download page that using shared variables with the requirement to install a costly DSC runtime on each customer's computer is not workable. Plus, I can't get an evaluation version to even show my customer how it would work.


I am required to provide my customers with Installer DVD's and the current situation does not allow me to do this because DSC is a seperate license.


I have Kudo-ed your idea and thanks for doing this.


Barry Galvin / GRAE LLC


Active Participant

I haven't used the NI Modbus library, nor have I purchased/used the SAPHIR offering.  Some time back I needed to communicate with a SMC valve controller using Modbus/TCP, and like others here, ended up "rolling my own".  Then I encountered the need with a totally different TCP device (Spectrum Power DC SmartStart), modified my library a bit, and re-used it.  Then a third device, this one RTU (AccuEnergy Acuvim-L), and re-used it.


Here were my goals in writing a library package:

- that it be pure-G (even though I'm only using it, personally, under Windows).  Why? Because that's the right thing to do, and takes no more effort. No DLLs, no NSV, DSC add-ons, etc.

- that it be built on VISA. Why? So I can support both Modbus/TCP and Modbus/RTU with the same library.  It tests the VISA class at runtime, so if you open a VISA SOCKET, the code implements TCP, if it's a Serial INSTR, the code uses RTU.


I didn't create a complete "solution" as I'm sure SAPHIR offers (no network explorer, slave emulation, etc).


If NI chooses to follow JB's idea, I hope they make it robust and platform-agnostic.


Until then, I can probably offer what I've got to others as long as it doesn't become too big a support time sink.



David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Trusted Enthusiast
Trusted Enthusiast

As far as I know, a new Modbus library has been written and is currently tested by NI. Unfortunately I don't know any details about it.

Thanks DavidBoyd for your interesting post and your proposal. I will contact you if NI's new library shouldn't be released till the end of this year.

Trusted Enthusiast
Trusted Enthusiast

"An experimental and unsupported version" of the new NI Modbus library has just been released and a discussion about it started.

"The library is distributed as a VI package, meaning that it requires JKI's VI Package Manager for installation."


Unfortunately, I don't have the time to try it right now.

The link to download the API is wrong (just redisplay the current page) and I can't found it in the JKI Manager.


Is anyone find the right link for the new version ?

Knight of NI

I wouldn't consider that link to be the NI modbus library.  It is a community example by "smithd".  I don't know how good it is or what it is based on.  The download links in there are definitely broken.  I wouldn't use it.


The "official" Modbus library is here MODBUS Library for LabVIEW. It is the latest I know of because it uses polymorphic versions of the VI's.  (The NI Modbus library before this one did not use polymorphic VI's.