NI Labs Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

NI LabVIEW Modbus API Discussion

Hello.

I believe I found a bug in the API.  I'm running a Serial Master session and sending e.g. a Read Input Registers request.  And I'm inputting a delay on the communication more than the set timeout, i.e. forcing a #56 timeout error.  When the data arrives from the Serial Slave moments later, the data will then just be waiting in the UART input buffer.  So on the next Read Input Registers request, the API will use the data the Serial Slave sent on the previous command.  The fix ought to be that the Serial Master should monitor the serial port at all times, not just when expecting a response from the Serial Slave, and throw away any received bytes coming in when not expected.

I haven't read all 15 pages of the thread to see if this has been reported yet, so bear with me if it has. 🙂

Bests Regards,

Øystein Johnsen.

0 Kudos
Message 221 of 529
(1,850 Views)

You are absolutely right that is the superior solution -- and no I don't think anyone else has mentioned this so its worth discussing in detail. The short answer is that it is never happening. The long answer is:

1. Unfortunately that would be essentially a rewrite of ~1/3 of the code

2. While this would work well with modbus TCP and ascii, RTU would require excessive CPU usage to constantly monitor the port because the wire protocol is a poor fit for modern OSs and abstraction layers.

3. It would also very likely make the master undebuggable due to a combination of confusing code (each read would have to have some sort of callback mechanism which the port monitor process can feed data back to) and limitations in debugging reentrant code on cRIOs -- which unfortunately has turned out to be a requirement thanks to the issues I mentioned above with the RTU serial protocol.

So, as much as it is the "right" answer, it isn't likely to be done. The right solution for someone who needs that functionality right now would be to use I/O servers, which do have a background process constantly monitoring the port. I'm not sure how they work around #2, but I guess they do.

Thanks,

Daniel

0 Kudos
Message 222 of 529
(1,850 Views)

Hello,

I have a problem of Modbus TCP API.

I have downloaded the toolkit of page : <a href="https://decibel.ni.com/content/docs/DOC-30140">https://decibel.ni.com/content/docs/DOC-30140</a> 

And I built a Master VI according the page : <a href="http://www.ni.com/white-paper/7675/fr/">http://www.ni.com/white-paper/7675/fr/</a> 

But when I run the program, error happened.

Here is the error information below:

 

The error 63 happened : TCP opens a connection in TCP Master.lvclass:Initialize Master.vi-&gt;Modbus Master.lvclass:Initialize.vi-&gt;API Main.lvlib:Create TCP Master.vi-&gt;Modbus TCP

Possible reasons: LabVIEW: Overflow of the reception capacity of the serial port. LabVIEW: the network connection has been refused by the server.


In fact, my system is in French, so the above error infomation is translated by me. I attach also the original information in French.

 

L'erreur 63 s'est produite à : TCP Ouvrir une connexion dans TCP Master.lvclass:Initialize Master.vi-&gt;Modbus Master.lvclass:Initialize.vi-&gt;API Main.lvlib:Create TCP Master.vi-&gt;Modbus TCP

Raisons possibles : LabVIEW: Débordement de capacité du buffer de réception du port série. LabVIEW: la connextion réseau a été refusée par le serveur.

 

My softwares are LabVIEW 2013 and RealTime 2013


Could you please help me ? Thanks.


Best regards,


C. SHU

0 Kudos
Message 223 of 529
(1,850 Views)

Hi,

The error described may have several reason. Any chance that you post your code or a simple example which reproduce the issue ?

Raphaël

Cordialement,
Raphael T
0 Kudos
Message 224 of 529
(1,850 Views)

Error 63 just means that it couldn't connect to a target. It looks from your VI that you only have a master. Do you have a slave running somewhere? If not, you'll get error 63.

Included in the package are two examples intended to be run on your local machine, side by side. I'd recommend looking into those.

0 Kudos
Message 225 of 529
(1,850 Views)

Thanks very much. Truly I didn't have any slaves. I will follow your recommendations. But I could not find the said package including two examples. Is that in a page to be downloaded or in the software files in my computer ? I searched with the key word "modbus" in my LabVIEW example files (after the installation of Modbus API toolkit), but I didn't find anything. Could you please give me the correponding file path or the website link? Thanks.

Best regards,

C.SHU

0 Kudos
Message 226 of 529
(1,850 Views)

Ah yeah, its actually on the palette, not the example finder. It should be bottom left on both the slave and master palette if I remember correctly. You can definitely find them under <vi.lib>\NI\Modbus Library\Examples.

0 Kudos
Message 227 of 529
(1,850 Views)

Thanks very much. According the examples, I created one slave vi. And it worked with my master vi.

0 Kudos
Message 228 of 529
(1,850 Views)

I recently upgraded to library v1.1.5.X

This version seems to have a bug when it attempts to communicate with itself. I have a serial slave host set up on main computer. Its communicated to a USB-RS232 converter. This converter is wirted to another USB RS232 converter which in turn talks to another labview program.

The host is running as a Modbus Serial Slave.

The Client is a custom application I'm testing.

When ran I get a Error 56 occured at RTU Data Unit.vlclass:Read ADU Packet.vi2 '

Issue exists with 1.1.5.38 and 1.1.5.39

0 Kudos
Message 229 of 529
(1,850 Views)

Thats surprising, what version were you using before? What are your timeouts?

Basically Modbus RTU relies on exactly proper timing and usb-232 dongles seem to mess up that timing. 1.1.something should have resolved this issue by basically being ridicuously accepting of whatever the visa driver says but every once in a while someone still runs into this. Maybe having two converters in series 😕

0 Kudos
Message 230 of 529
(1,850 Views)