NI Labs Discussions
NI LabVIEW Modbus API Discussion
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.
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
