NI LabVIEW Modbus API Discussion

[J.Harv]

This morning I found a post earlier in the thread (post #62) for notifying the slave that data was written by modifying the data model.  Just looking at it, I believe it relies on the master setting an occurence.  I don't think this will work for me since I don't have control over the master code.  Is that right?

[smithd]

Hey John, lots of questions so I'll try to break this up...

J.Harv wrote:

All of the functions here work with their implementation, so that's a good check for both sets of code. The only unique thing is that it's written such that the cRIO and the PC both are a master and a slave.  I haven't seen this discussed anywhere, but I don't think that's a problem, is it? Anyway, everything that's been implemented is working fine. I have my code, using this API, setup to function as both master and slave and I'm reading all data fine.

I'm not sure what you mean--are you saying you're using both a master instance and a slave instance? Or was it something else? Sounds like this is working but just wanted to clarify.

J.Harv wrote:

1.  Custom functions.  They've implemented function code 65 (x41) to pass a large amount of waveform data.  I thought I saw a post here that might have been what I wanted, but I wasn't clear on how to actually do it.  I'm not familiar with OOP at all.  I did see the link posted to the LAVA presentation, which I'll look into right after this.  I'm guessing this extra function gets added to the "Standard data model"?  Is there an example I missed in the thread?  or maybe a short/very brief bulleted list of steps would help?  Whatever response, I think I just need to be pointed in the right direction.

For this I'll be referencing the classes here: https://decibel.ni.com/content/message/54995#54995

For the slave, you need to create a child of either the Data Model or Default Data Model (I'd recommend Default for now) class. Then, when initializing your slave, you can pass that data model in to the create slave instance function (there is an optional input, position 3 on the left). Then, within the data model you need to override vi.lib\NI\Modbus Library\Standard Data Model\Execute Function.vi. This function takes a PDU and decides how to process it. Basically you need to have a case structure such that if request code = Blah, do your new function, else call parent method (so things like registers are still handled correctly). I think this serves as a basic example: https://decibel.ni.com/content/message/72889#72889

Some instructions here: https://decibel.ni.com/content/message/73004#73004

For the master, a custom function code would be implemented quite simply by copying one of the existing requests and editing the code to generate the appropriate request. There is an example here: https://decibel.ni.com/content/message/58374#58374

J.Harv wrote:

2. For the slave, how can I tell when the master has written a value to me.  Data needs to be shuffled off to other loops as soon as it's recieved.  We have a very large list of registers and reading all of them sequentially, or otherwise, is not going to work well.  I'd like to monitor for this incoming data from the master, determine the register, and move the data in a direct, timely fashion.  Can I pull out the modbus response somehow?  or maybe get some notification I was sent an update from the master?RC (a type of checksum).  I don't know what the specific checksum method used is

This morning I found a post earlier in the thread (post #62) for notifying the slave that data was written by modifying the data model.  Just looking at it, I believe it relies on the master setting an occurence.  I don't think this will work for me since I don't have control over the master code.  Is that right?

Its simpler than that. The only reason the occurrence is set in the main is to make the code stop. If you open the example in that post and go to Datmod2011\Execute Function.vi

you'll see that all this requires is the same changes I listed for your question #1. Except here in addition to calling the parent method, I set an occurrence letting other code know that something happened. A queue or user event would give you more information and would be generally more useful, but its just a demo.

J.Harv wrote:

3. I took your advice earlier on snooping the network to help debug and downloaded Ethereal and the CAS Modbus TCP parser.  I haven't been able to get the parser to work, no matter what I've tried, it says no modbus messages found. Whatever. From the Ethereal logs though I did notice that TCP CRC fails checksum fails on all queries and responses from the API.  The cRIO (custom modbus code) did not have this issue. Have you seen this before?

No I haven't seen that, kind of weird. I think wireshark has a setting to enable TCP checksum checking, so it may be that if you have it turned off it reports that the checksums are invalid...but that doesn't explain why they are valid from the other API. Anyway, all its doing is writing straight to LV TCP so its not anything to do with the API. Wireshark should be able to parse out modbus packets, I think you have to type in proto==mbtcp or something along those lines for the filter.

J.Harv wrote:

4. We're only using holding registers.  No input, coil, or discrete.  I'm wondering how big a performance hit I'm taking by initializing those 65xxx size arrays for each of the extra 3 data types, passing them around, and then never using them? What are your thoughts on removing them for better performance?

Its only 253 kB which is why I made the choice to initialize it without giving people the option. If its an issue, you *should* be able to make an exact copy of the default data model and then delete the parts you don't like.

Thanks,

Daniel

[J.Harv]

Daniel-

Thanks so much for the reply.  I'll be looking at this off/on over the next few days due to other responsibilities, but I wanted to give a quick reply now.

--Notify and custom data.  Looks like enough for me to go on.  I realize it's been posted before, sorry about that.  I guess I didn't know what I was looking for.  Thanks for summarizing again.

--Checksum.  Yeah, it doesn't seem to cause a problem.  The bad checksums were reported by Ethereal, which I was trying to use with the CAS Modbus Parser.  I have switched to Wireshark, which doesn't complain about the checksums.  It's also a more powerful tool overall.  I found with Wireshark the Modbus decoding happened automatically, at least with the latest version.  That's been a very valuable tool.

--Extra data types. Just checking.  Good to know that would be ok if I ever feel like doing that, but for now I'll just leave that alone since there's probably not much gain versus even the small amount of work to remove them.

Regards, 
John

Edit:  Oh, and to answer your questions, yes, each node (PC, PLC, touchscreen, RIO) has both master and slave instances. 

[smithd]

Yeah I read somewhere that ethereal turned into or was bought by wireshark or something, so I figured you were just using the older name. The current edition of wireshark is definitely powerful and recognizes most of the critical parts of a modbus frame.

Either way, the rest sounds like you're on the right track. Let me know if you run into anything else.

[Mrmas]

Hi Smithd,

I am having a problem where I have used this library previously and now am moving some code to RT and it is conflicting with the new built in RT modbus library in labview 2014. Which in itself would be fine, I could remove this and only use the recommended one for RT.

But the RT modbus library does not support normal targets, so if i want to make a modbus client/master on a regular windows pc to talk to a modbus slave on a RT target I cant use either library.

Is this working as intended or is there a workaround way to install this library without conflicting with the RT one. Before this the library has been working very well, and i do not really see another suitable option for modbus on normal targets.

Regards

[Valarauca]

Use different tools for different tasks.

Provided both conform to the same standard they'll interoperate with one

another.

RT platforms make a lot of different assumptions about threading and user

latency tolerance which makes writing cross platform code difficult, as it

would require a higher level meta-programming language that labview largely

lacks.

[Mrmas]

I would not mind using the two libraries amoung one another, but if i install the modbus API from this thread the RT API gets all sorts of compability errors.

If there is a way to have both librarys installed and used at the same time I would see that as a complete solution.

Perhaps i am just installing/linking the libraries wrong?

[smithd]

There is an error with the palettes. The modbus library is fully supported and fully functional under both windows and RT targets. If you had LV DSC installed you'd see the library show up under windows. The intent (or at least my intent) is that its more like OPC UA where installing it makes it show up under both targets.

The workaround is to add it yourself or to just work under an RT target to grab the appropriate items. You could also add some of the classes to your project where they're easy to access.

Finally, I generally wouldn't recommend having both versions installed. If thats something you want to do for whatever reason (and there are some valid reasons) you could pretty easily wrap the old version of the code in a higher level lvlib file (for namespacing) or rename some of the classes so there is no conflict. This is something I've considered doing but then it would break backwards compatibility so I've left it alone.

[Agallegos]

hi,

im working with some equipment that works with UDP protocol and im looking for some like Modbus UDP library

[smithd]

Modbus UDP is not a standard, but there are implementations. For example Jamod (java modbus) support it, as does this apparently:

http://www.easymodbustcp.net/

I can't imagine why you would use Modbus UDP instead of TCP, so if your device supports both I'd go for tcp. If you absolutely need to support UDP, this modbus library has a plugin mechanism for supporting additional transports like UDP. Thats the conn interface you see in the class diagram on pg 1. You'd create a new child of the master connection class which supports UDP instead of TCP and then everything should work.