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
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?
I developed in 2012 and, due to the complexity, I was reluctant to revert. I'll see what I can do, though.
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.
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.
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?
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.
Will you include Modbus UDP support?
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 ?
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.