NI LabVIEW Modbus API Discussion

[reto]

Very god job made Thanks.

In the past, we have written our own MODBUS slave interface for the cRIO, as the old library was not able to response to incoming MODBUS message within the required answering time of only 5ms.

For a new SW (on a PC) I will try the new API J After reading the documentation and playing with the sample code, there is already the first question:

On a slave implementation, is it possible to get an event (or something I can poll on) to verify when the master sent a request to the slave? Our client requests a free running counter, incrementing each time a valid MODBUS message is received / processed.

Reto

[perhult]

Hi

I have two devices connected to a USB-RS485 converter (serial RTU modbus). With the old modbus library my application works fine, but the polling is a bit slow and CPU usage higher than should be nessecary

With the new library, I get up to seven times faster polling which is nice (I also find the organisation of the new library very good!). However, after a few minutes I always Error 56 at an unidentified location (LabVIEW:  The network operation exceeded the user-specified or system time limit.).

This is a built application running on a ordinary computer.

Anyone have an idea why this happens? I can attach the vi if anyone cares to look at it.

[smithd]

Reto,

Yes, this is actually straight forward but not well documented. I swear I made a sample earlier in this discussion but I can't find it, so maybe I didn't. Steps are as follows:

1. Create a new lv class and name it something like event-based model
   1. Make this class a child class of the standard data model: C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\NI\Modbus Library\Data Model\Standard Data Model
2. Add an event refnum or counter reference or something to your class so it knows what to do
   1. Create an initialization function which sets the class up for you (or just use some sort of accessor method)
   2. you can also override the function initialize.vi inside of the standard data model, so long as you make sure to call the parent method.
3. Override Execute Function.vi to do what you want

I've attached an example of this. Its kind of gross but should be sufficient.

Thanks,

Daniel

[smithd]

Hey Perhult,

Error 56 is returned in exactly the expected situation--a response is not received. I assume this is the master side?

My suggestion as a starting point would be to monitor the port using NI I/O Trace (or similar) and see what happens when the timeout occurs. If you are getting data on the port it might be an issue with the library. On the other hand the consistency of the error could mean it is slave-related or converter-related.

Thanks,

Daniel

[perhult]

Hi

That's right, it is master side. I used I/O Trace earlier but I did not find anything, however I might not know how to use it and interpret the logs good enough. I should have asked earlier, now the hardware and application is at a field test 200 km away (although I have a remote desktop connectioon to the site so I might be able to try some I/O tracing) I will post the trace here in that case.

I have two slaves (pressure transmitters), and when using proprietary software from the transmitter manufacturer they work without timeouts, even slighty faster than with the new library. With the old library (identical program layout as with the new library) they are slower, as I mentioned, but they never time out.

So I am a bit suspicious...

But one question, why is the timeout error "at unidentified location"? I think the error is a bit confusing, if it had included the word "timeout" I would have understood it better right away.

[Icebaer]

Hi,

today I have downloaded the last version 1.0.10.23. First I have tried the Modbus Slave Example for a communication with a HMI (Modbus-Client). If I start the example then I get the Daemon error code 1003: VI-Referenz öffnen in TCP Slave.lvclass:Launch Handler.vi->TCP Slave.lvclass:TCP Daemon.vi:10->TCP Slave.lvclass:TCP Daemon.vi.ACBRProxyCaller.23D00020<APPEND> VI-Pfad: <b>C:\Program Files\National Instruments\LabVIEW 2012\vi.lib\NI\Modbus Library\Network Protocol\Network Slave\TCP\Connection Handler.vi</b>

If I open the Connection Handler.vi then this VI shows the following error.

I use LV2012 SP1. Do somebody knows the reason of this error? Thank you.

Thanks,

Sven

[smithd]

perhult wrote:

Hi

That's right, it is master side. I used I/O Trace earlier but I did not find anything, however I might not know how to use it and interpret the logs good enough. I should have asked earlier, now the hardware and application is at a field test 200 km away (although I have a remote desktop connectioon to the site so I might be able to try some I/O tracing) I will post the trace here in that case.

I have two slaves (pressure transmitters), and when using proprietary software from the transmitter manufacturer they work without timeouts, even slighty faster than with the new library. With the old library (identical program layout as with the new library) they are slower, as I mentioned, but they never time out.

So I am a bit suspicious...

But one question, why is the timeout error "at unidentified location"? I think the error is a bit confusing, if it had included the word "timeout" I would have understood it better right away.

The timeout error is "at unidentified location" because I manually created the error cluster rather than using one of the lv functions, so the source field is not filled in and labview presents it at being an unknown source. Just an unfortunate habit from working on RT code--less string manipulation is good . However I tried to make sure every timeout situation is reinterpreted as error 56, since that is sort of the standard network timeout error in LabVIEW.

I tend to agree with you on the suspicous nature of the change, but honestly the core serial piece is pretty much the same. Thats something I'm interested in fixing, but hasn't been done.

[smithd]

Icebaer wrote:

Hi,

today I have downloaded the last version 1.0.10.23. First I have tried the Modbus Slave Example for a communication with a HMI (Modbus-Client). If I start the example then I get the Daemon error code 1003: VI-Referenz öffnen in TCP Slave.lvclass:Launch Handler.vi->TCP Slave.lvclass:TCP Daemon.vi:10->TCP Slave.lvclass:TCP Daemon.vi.ACBRProxyCaller.23D00020<APPEND> VI-Pfad: <b>C:\Program Files\National Instruments\LabVIEW 2012\vi.lib\NI\Modbus Library\Network Protocol\Network Slave\TCP\Connection Handler.vi</b>

If I open the Connection Handler.vi then this VI shows the following error.

I use LV2012 SP1. Do somebody knows the reason of this error? Thank you.

Thanks,

Sven

You know, this is the second very odd error I've seen with that build. It doesn't happen on my machine, but the person who reported the error in the first place had issues with a VISA property node.

For now, please use the attached patch over version 1.0.9. Place the contents in this folder: C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\NI\Modbus Library\Serial Shared Components

If you still see this error, then...I'm not sure. I'd have to look into it some more.

[Icebaer]

Hi smithd,

thank you for your answer. Now I have installed the version 1.0.9 and with this version and without the patch I haven't the described error. Should I install the patch anyway?

The Modbus Slave example works and I get a connection to my HMI with the Modbus Master. But if I stop the Modbus Slave Example then I get the Daemon Error Code 60 and a reconnection isn't possible. I must restart LV completely to re-establish the connection over the Modbus Slave example. However if I stop the Master and start it again then the reconnection works without problems.

I would like realise the following steps: 1.) Open a connection to the Modbus-Master (HMI) 2.) Write/Send a input register with a number to the HMI 3.) The HMI answers with the same number over a holding register 4.) Compare the numbers 5.) Close the connection. During this steps the Modbus-Master runs all the time. Later I must call this VI over TestStand 2012.

What's the best procedure?

Thanks, Sven

[perhult]

Now I have run I/O Trace. Feel free to look at the log. Sorry for the size, but I could not get it to stop at error, because I get Timeout errors all the time that does not seem to affect the execution, so I had to run without "stop at error".

However, when I actually get at Timeout error in the application, there is no error in trace... 😃

The error should be at line 98921 or somewhere close in the trace.