NI Labs Discussions
NI LabVIEW Modbus API Discussion
Thank you for the two links. I didn't recognize the first one, though it's just one page back, sorry. 
But give me some time to go through them.
Meanwhile let me give you some examples for applications where I think a user defined data model would be an interesting thing:
- Unit ID in TCP slaves could be used to distinguish different subfunctions or subdevices. For example a main device could collect data from subdevices (RTU or TCP) and map each to one Unit ID. A local bus like with RTU could be realized with TCP as well using a secondary eth port. But the mapping of RTU devices was covered here before...
- You could define that parameters will be accessed through unit ID 1, control values through unit ID 2, etc..
- Imagine, you have one device with one function A, using a certain set of registers A of the device, and there is another function B with a consecutive register set B. Now I would like to ensure, that functions A and B are only called if all registers of the set are given. Also, if in an attempt to write set A, the starting registers are not given correctly (typical problem: Registers start with 0 or 1 in my new modbus tool?), I need to prevent that my device goes crazy because sets A and B are bot accessed partially.
- In my understanding, modbus allows in general any register to be called with any function code. But the application has to define, which may be red or written for a specific device. The protocol provides a suggestion with four blocks, but this is not mandatory. Also I think it's not implemented in your standard data model, is it?
- I simply would like to signal to my technician: This register you're looking at is not used any time and will never show any data by giving exception code 02 (ILLEGAL DATA ADDRESS).
gnshmrthy wrote:
My Questions?
There are lot of versions available in Modbus API which one should I use for my system?
So, you're asking that question on a thread which is a discussion of a specific modbus library. I'm biased 
That having been said, if you don't have LabVIEW Real-Time or LabVIEW Datalogging and Supervisory control then you probably should be using this version of the library. The old TCP library should also work well as a master, but using the library in this thread will give you an easier upgrade path if/when you move your code to 2014 and if you ever need to support a slave.
Sorry, don't think I got a notification on this.
SKauth wrote:
Thank you for the two links. I didn't recognize the first one, though it's just one page back, sorry.
Meanwhile let me give you some examples for applications where I think a user defined data model would be an interesting thing:
- Unit ID in TCP slaves could be used to distinguish different subfunctions or subdevices. For example a main device could collect data from subdevices (RTU or TCP) and map each to one Unit ID. A local bus like with RTU could be realized with TCP as well using a secondary eth port. But the mapping of RTU devices was covered here before...
- You could define that parameters will be accessed through unit ID 1, control values through unit ID 2, etc..
-So, a modbus slave is a representation of memory to the system. This API as is defines unit IDs on the link level. To make your proposed solution work (multiple logical slaves on a single physical slave) you'd have to transmit the unit ID with every single request, both local and remote. Another perfectly reasonable solution would be to instantiate multiple TCP slaves on different ports, which would get around the issue entirely. The standard port (502) would be read-only and then you could have a second connection on a more obscure port which would give you control access.
-I also don't like this because it feels like you're trying to add modern features to an ancient protocol running on a modern device. I understand using modbus in some cases for backwards compatibility, but for a whole new design I'd definitely move towards something more advanced like OPC UA.
SKauth wrote:
- Imagine, you have one device with one function A, using a certain set of registers A of the device, and there is another function B with a consecutive register set B. Now I would like to ensure, that functions A and B are only called if all registers of the set are given. Also, if in an attempt to write set A, the starting registers are not given correctly (typical problem: Registers start with 0 or 1 in my new modbus tool?), I need to prevent that my device goes crazy because sets A and B are bot accessed partially.
...
- I simply would like to signal to my technician: This register you're looking at is not used any time and will never show any data by giving exception code 02 (ILLEGAL DATA ADDRESS).
-I would argue the indexing issue is something you should hammer out in testing but I definitely understand the situation. This kind of behavior is exactly what the data model was intended to handle.
SKauth wrote:
- In my understanding, modbus allows in general any register to be called with any function code. But the application has to define, which may be red or written for a specific device. The protocol provides a suggestion with four blocks, but this is not mandatory. Also I think it's not implemented in your standard data model, is it?
-This is incorrect. Modbus defines function codes accessing metaphorical data but has no restrictions on the implementation of that data. In the standard data model, the data is interpreted to be literal banks of 65,535 registers, input registers, di, and coils. You could easily change the data model to have each function code accessing the same dataset, although this wouldn't make much sense. Anyway, the defined functions are what restrict access. There is no function code for writing to input registers, thus input registers are read-only, even though modbus doesn't define what those input registers actually are. On the other hand you can write to or read from holding registers, giving them r/w access. The standard data model implements all four blocks and the main function codes associated with each.
