NI Labs Discussions
NI LabVIEW Modbus API Discussion
Hey prose,
I could have sworn I replied to this. Oops. So, I definitely agree that its one big dependency (technically four, actually--one for coils, one for DI, one for registers, one for input registers...but I get your point). However, thats going to be more or less true of any global dataset in LabVIEW.
It is also true to say that using a variant attribute could work, I would caution against it for performance reasons (depending on the needs of your application). If you look into the CVT, you'll notice that I used a variant attribute to look up the index of the tag in the dataset, but kept the actual data separate. That allowed me to cache what was essentially a pointer and re-use it without paying the lookup penalty. It also allows for super-fast performance when needed, as you can look up all data indices when your program starts and just re-use them in your code.
To clarify, this is essentially what I was suggesting (for one of the options--the other was just copying everything as you say):
Instead of adding additional layers of indirection, the "holding register" values are replaced with clusters, and these clusters contain a data type, and a cvt index (or potentially N cvt indices, as for booleans or U8s, and potentially a length, if you wish to support fixed-size strings). It would probably also have a "valid?" flag, to make sure requests don't come on boundaries of multi-byte data like floats or singles. The point is, when the request comes in saying give me holding registers 0 through 44, you go to this lookup array and step through it element by element. As you step through this lookup array, you are actually reading from or writing to the CVT.
But yeah...if you only have 50 variables than I think most of these concerns are not a big deal. The action of reading or writing in the slave code is pretty fast (replace array subset or get array subset, basically), so I doubt you'll ever notice an issue with the data being locked for too long. Its also worth noting that a slave accessing its own data space is not a network operation and thus respects priority inheritence. That is, if you are reading from the slave interface in your timed loop, it will respect the fact that this is higher priority than the network listener loops.
Thanks,
Daniel
p-rose wrote:
I'm not too concerned about writing data to the modbus slave loop because the calling code can just send a message to the modbus loop and move on, it's a "set it and forget it" kind of operation. On the other hand, reading data out of the modbus slave data space from multiple places presents a scalability challenge because the entire application is throttled by how fast the modbus slave loop can process simultaneous requests. It's one giant dependency. Calling code has to wait to be serviced.
To try and decouple it, I need to copy the modbus variable data into a super fast mechanism that uses key (string)-value pairs so that I can quickly get a value by "tag name". Maybe a solution is to use a variant attribute lookup table in my custom data model's "execute function" vi. The details are still a bit fuzzy but I think it could work. I would have to use your unpack PDU vi's to give me the function code and start address. From that I would form a string to do a lookup on a variant attribute LUT which would return a cluster containing the "tag" name and data type (size inferred from the datatype). Then I'd have to get the new value from the PDU data or perhaps after calling the parent "execute function" and then shove it inside another variant LUT which resides inside of a FGV that I can use throughout my application to get the value by "tag" name. Obviously this would only work if my HMI only writes one value at a time.
Maybe your idea to update all variables on any write would be OK for me. I only have 50 or so variables at this point. That would certainly be easier.
I would be intersted in unifying the CVT and this library. I find myself needing these two technologies fairly regularly. It would be nice to combine the best of both worlds.
Hi DaHelmut,
Thanks for the feedback. On the topic of Unit ID, thats a known issue with the documentation...its not technically incorrect, it just isn't very clear. What it is trying to say is that you can set the unit ID, but all of the code you're using (all the master code) will completely ignore it. It doesn't mean that the slave will ignore it. That is, setting the unit ID will do exactly what you want it to do 
I believe I mentioned this previously in the thread but its faster to mention it than find it. The tcp wire is completely reference based, meaning that if you have N identical slaves on your rs485 network that you wish to communicate with, you can split the wire and everything should still work. The way I see this happening is like so:
The create master initiates the connection, but you can create N copies of that connection (since it is by-reference) and assign a unit ID to each of the copies. There is more going on under the hood to make this work, but it should meet your needs.
Thanks,
Daniel
DaHelmut wrote:
Hi everybody,
I just played around with the Modbus API today and this is a very cool library.
It is a very intuitive API and very efficient.
However, in the case of using an Ethernet to RS485 gateway with several RS485 slaves chained together the TCP/IP Master is not usable because we cannot set the slave ID (Set Unit ID.vi) since it is ignored with a TCP/IP transmission data unit according to the VI documentation.
Is there a way to modify the library to take it into account ? Is there a workaround ?
My thoughts are that you created the TCP/IP Master to only adress one slave that is also a TCP/IP slave and not a gateway.
Thanks in advance for your answers.
Have a nice day !
Regards,
It says Illegal Data Address (error message posted in my previous post).
That it sends the UNIT ID with read requests doesnt mean it also sends it for writes I think (different code?)
My read request fore node 4 is address 10, 1 register. I get a value returned nicely. When I try to write to this exact same address I get the errors.
The node address and timeouts are set before the function code 16 is called. As the VIs are password protected I have no clue what is going on
