topic Re: NI LabVIEW Modbus API Discussion Eurotherm 3504 in NI Labs Discussions

NI LabVIEW Modbus API Discussion

smithd — Tue, 21 Jan 2025 20:16:59 GMT

This thread is intended to foster discussion about the LabVIEW Modbus API project, so please post your questions, comments, suggestions and bug reports and I'll be happy to respond.

Modbus is a communication protocol which is used as a de-facto standard in many industries, primarily as a serial or TCP/IP protocol. This API includes both master and slave support and can run on both PC and RT targets.

One of the goals of this release on NI Labs is to get a better idea of what features are in most demand, the usability of the API, and garner feedback from our users.

To download the API, or to read more about it, please go to LabVIEW Modbus API

Re: NI LabVIEW Modbus API Discussion

PCasado — Wed, 10 Jul 2013 08:49:13 GMT

Hi D_Smith,

Currently I am using Labview 2011 on my laptop because 2012 labview runs a bit slow and I am interested in Modbus API but it is only compatible with labview a 2012 version. Could it be possible to generate a 2011 modbus library?

Thank you

Re: NI LabVIEW Modbus API Discussion

smithd — Wed, 10 Jul 2013 15:57:09 GMT

Hey PCasado,

I developed in 2012 and, due to the complexity, I was reluctant to revert. I'll see what I can do, though.

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

dwisti — Wed, 10 Jul 2013 18:32:24 GMT

In the same boat, would love to see this for Labview 2011. I have my own Modbus library I developed back in the 8.5 days. The protocol isn't that hard to code but I would love to see how you implemented the API. Please tell me you did this without dll calls.

Re: NI LabVIEW Modbus API Discussion

smithd — Wed, 10 Jul 2013 19:54:06 GMT

2011 Version is attached. To preempt any requests for 2010, I attempted to save back to 2010 and was unsuccessful.

As for implementation, I'm not sure that having the code would help too much since I locked a significant amount of it, for now, since we're still looking into if/how this might become part of the product. However, I'm more than happy to give you a basic rundown, and there are definitely no dlls. Instead it uses classes to try to abstract the different levels of the protocol:

From left to right:

-Data model defines the interface to the data stored on the slave, and the interface for how modbus function codes can change the data. The Default data model is the basic implementation of it, which uses DVRs to store the data and defines an implementation for reading most function requests and responding to them.

-Modbus PDU is basically a cluster. I only made it a class because everything else was. It consists of the function code and an array of bytes to be sent as the request.

-ADU definition is a much more detailed component. In the spec we define a header and general behavior depending on if the packet is a RTU serial, ASCII serial, or TCP packet. This was separated from any other class because I have had situations where, for example, people have desired to have a RTU packet transferred over a different bus like TCP. So, this ADU definition defines how we take the PDU and pack it into a bytestream for transport, or how we take a bytestream and unpack it into a PDU.

-Function definition defines how the master generates request PDUs and unpacks response PDUs.

-Conn interface defines how we take the bytestream provided by the ADU definition and transmit it across the network. These functions actually call into a separate library (not shown) which provides a consistent interface for both the serial and tcp sides (visa doesn't provide the same event-like interface that TCP does, so I implemented one). The children shown are also interfaces (the implementations are not shown--they are simply TCP and serial). The slave interface defines a daemon and how to initialize that daemon. The master interface defines how to initiate a connection on the desired protocol (for example, serial sets port settings like parity).

-Finally, the API interface defines how the user interacts with the rest of the code, and manages the other classes for you. For example, the master will generate a PDU and pass that to the rest of the code, while the slave API directly contacts the data model.

Re: NI LabVIEW Modbus API Discussion

PCasado — Thu, 11 Jul 2013 06:41:53 GMT

Hi Daniel,

Thank you for your help. I will try this on my computer an see how it works.

Thanks.

Pablo Casado

Re: NI LabVIEW Modbus API Discussion

JensG69 — Thu, 11 Jul 2013 18:35:00 GMT

Nice to see that the old NI Modbus Library gets a redesign.

I currently see that a lot of Modbus Slave Units support Modbus UDP & Modbus TCP.

Will you include Modbus UDP support?

Thanks, Jens

Re: NI LabVIEW Modbus API Discussion

smithd — Thu, 11 Jul 2013 19:27:25 GMT

There are no current plans for that, as the original goal was to replicate the functionality of the original modbus library.

Besides that, I don't know that there is an official spec, so I feel it would be inappropriate for it to be included in this library for the initial release. The only reference I can find to a specification of modbus UDP comes from this Java library: http://jamod.sourceforge.net/kbase/modbus_udp.html

I don't know how realistic this is, but my dream would be for customers or other users of the code to extend the library and post those extensions to the web. If you follow that JAMOD spec above, all that would be required would be an override of the slave interface and master interface code--basically, an override of 6 VIs in total.

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

Olivier-JOURDAN — Tue, 21 Jan 2025 20:17:52 GMT

jg69 wrote:

Will you include Modbus UDP support?

Thanks, Jens

Hello Jens, as developper in charge of the ModBusVIEW add-ons available on the LabVIEW Tools network, I'm really interested by this thread. Concerning your UDP support request, like Daniel I'm not aware of any official spec about that. From what I know, I think that UDP is not appropriate for an industrial communication protocol because it cannot guarantee the delivery of the request. Is it possible to explain us the reason why you need this ?

Thanks,

Re: NI LabVIEW Modbus API Discussion

JensG69 — Fri, 12 Jul 2013 08:37:37 GMT

Hello

I'm aware that there is no official spec about Modbus UDP and I also do not need it currently.

I just happen to see in quite a few specs of different Modbus slave units (like e.g. Wago ethernet fieldbus coupler) that Modbus/TCP AND Modbus/UDP is supported.

If the NI-Library gets rewritten why not include it? Just my 2 cents...

I'll have a look at the new library on the near future.

Regards, Jens

Re: NI LabVIEW Modbus API Discussion

Solarman — Wed, 14 Aug 2013 16:33:42 GMT

Hi Daniel,

I downloaded the 2011 version and I'm trying to use it to test a Modbus gateway.I used the example and reconfigured it for serial coms. It seems to comunicate OK and I can get the VendorName, ProductCode, and MajorMinorRevision plus more if I change to Read Regular using the Fetch Basic Objects. However, I can't seem to read the Discrete Inputs or the Input Registers. I've tried both RTU and ASCII.

The device is read only with 11 DI's (Function 02 address 0x0000 to 0x000A) and 18 AI's (Function 04 address 0x0000 to 0x0017). I can't see why it shouldn't work so any help would be appreciated.

Regards

Paul

Re: NI LabVIEW Modbus API Discussion

smithd — Tue, 21 Jan 2025 20:18:26 GMT

Hey Paul

Sounds like most of the code is working well, since Fetch Basic Objects is the most complicated function we have, but there may have been some other issues introduced. Can you:

(1) Describe what errors are occurring?

(2) Try this older library and tell me if you see the same issue: http://zone.ni.com/devzone/cda/epd/p/id/4756

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

Radiator — Fri, 23 Aug 2013 10:10:39 GMT

Hi Daniel

We are just implementing the Modbus protocol in an embedded device and I am creating a test tool. I would like to be able to see the entire RTU frame so we can log individual packets and check our implementation. Is this possible through this API?

Thanks

Ray

Re: NI LabVIEW Modbus API Discussion

smithd — Fri, 23 Aug 2013 16:57:48 GMT

It is not currently possible with this implementation because that particular VI is password protected. I can think of a few options:

-Serial uses NI-Visa, so you can use NI I/O Trace to track all serial activity

-You can use the existing free library

-Depending on your needs I may be able to provide you with a VI you can use for this purpose. If the first two options don't work for you, let me know a little more about what information you need and what sort of format you'd be looking for.

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

Radiator — Wed, 28 Aug 2013 08:00:05 GMT

Hello Daniel

Thanks for the information. It looks like I may have another issue which is that we wish to use the diagnostic functions (function code 08). I cannot see this functionality in either library, do you have plans to add it to the API? Regarding my original query, the NI I/O Trace facility works but is a bit cumbersome for looking at the packets, so I will probably use the older library for tracing.

Thanks

Ray

Re: NI LabVIEW Modbus API Discussion

smithd — Thu, 29 Aug 2013 04:49:02 GMT

Hey Ray,

I sent you a PM which may help with the serial stuff, but I understand that the locked nature of the code makes it difficult to do the low level things you want to do. I'm definitely glad to hear that feedback.

Re: function code 08, there are no current plans to add that to the new api and the old library was never actively developed. This is the case because it didn't seem like this was too commonly requested. However, its actually really easy to implement the master half of the protocol in this library. Function code 08 is relatively complex, but I'd be happy to help you along that path if you're interested.

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

S1ack — Tue, 03 Sep 2013 12:29:18 GMT

I am currently using the old Modbus library - and having some issues (vs. Ethernet/IP which I took out).

1) Does this toolkit run on cRIO hardware?

2) Any chance it might help with my CPU issue? Linked above - Indistrial Comms area on NI forums.

If any Modbus gurus have anysuggestions / answers for my question posed in the link above. I would love to hear it.

I have already tried polling the MB Ethernet Slave Demon on the other NIC (as the secondary is probably tied up with it's own master-polling-slaves data).

Re: NI LabVIEW Modbus API Discussion

smithd — Wed, 04 Sep 2013 00:12:42 GMT

I already posted in the other thread, but to answer your specific questions:
1) Yes, the toolkit runs on cRIO, but the example does not. I chose to make it use events, which makes it windows only.

2) One of the major changes to the code was improving performance, especially on the slave. So yeah, if you need faster responses at lower CPU usage, go for the new library.

Thanks,

Daniel

Re: NI LabVIEW Modbus API Discussion

S1ack — Wed, 04 Sep 2013 15:21:30 GMT

Am I missing soemthing that needs to be on the cRIO target (9074)?

Because it crashes and reboots when I attempt to run this very basic slave. Either within my project, or by it's self....

If there is anything usefull in the consol crash report I have that.

Re: NI LabVIEW Modbus API Discussion

smithd — Wed, 04 Sep 2013 23:02:11 GMT

Hey S1ack,

When you say crash do you mean error or that the VI simply stops executing? If it is an error, let me know what that is--it shouldn't require anything special. If it stops executing, check your memory usage during deployment and after it starts running (via distributed system manager or the sysconfig api). It may be that you are running out of memory? I wouldn't guess this with a 9074, but with a 9072 I managed to kill off the process because I had wayyy too much stuff installed (shared variable engine, web services, etc.)...but then the 9072 has literally half the memory of the 9074. Worth a check though

Thanks,

Daniel