Linx for Labview 2020 Error 5003

[GercinG]

My final solution was to remove the interruption from Arduino MPU 6050 to Arduino pin Rx, only used four-terminal 5v-gnd-A0 and A1

that's all.

GERC.

[Vasilich2004]

NI provides suggestion https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019SC2SAM&l=en-US but it isn't useful.

In my case it happens when application uses I2C device on Arduino. I think it happens due slow Arduino internal or external device, like AI in NI article or I2C device. It happens when

1. LabVIEW application sends first command through COM interface

2. LINX application in Arduino starts to process first command

3. LabVIEW application sends second command but LINX application hasn't finished to process first command.

Probably, LINX application in Arduino hangs USB interface and COM port over USB interface doesn't work at all. If you would get -5003 error you can try simple Serial test LabVIEW example to see that example gets Serial port from Windows but can't write any data!

Another confirmation that the issues is in Arduino is that this error disappears after rebooting Arduino device.

Suggestion to set delay in Packet Number.vi helps because it slows down communication. For example, LINX Blink example can send command 400 times per sec. When 500 ms delay would be added then LINX Blink example will send command 2 times per sec! But such approach will slow down each command!

So bug is inside of LINX application in Arduino. LabVIEW application could avoid this bug if it would add delay for slow device. For example, LabVIEW application works "I2C write -> Delay XXX mc -> I2C read" instead of "I2C write -> I2C read".

[rolfk]

Adding delays to device communication to make it work is about the worst bugfix you can do.

It slows down communication unnecessarily, also for the devices who would be fast enough and you can never be sure that you will not run into a device that is even slower than the one you test with. Sure you can increase the delay to be on the safe side, but then you are even slower!

NI-VISA, which is used under the hood for serial communication in Linx, is very capable of not overrunning the device if it follows a few basic rules. And the Linx protocol used has a command-response pattern, where every command is acknowledged with a response by the client and VISA simply waits for this response before returning from the command VI you called. If that timeout is to short for your device to answer, this is where one should start with debugging. A longer timeout gives slow devices more time to respond but doesn't slow down communication with faster devices that can answer quickly.

[DuffD]

I agree that it might be the worst bugfix, but in a pinch if it works, it works. 

It has been a little bit since I touched this project, but based on my initial solution I don't think adjusting the timeout fixed the problem. Once the Arduino was initialized and running the command and response structure and default timings worked fine. The hang up was in the initialization. I first noticed this when I ran the program in with the Highlight Execution (for the new programmers, that is when the lightbulb is turned on). With highlight execution on the Arduino would connect with LabView with no issues. After some digging I found that LabVIEW was expecting a response before the Arduino had finished initializing and would throw the error from there. By adding additional time to the initialization sequence the Arduino could finish what it was doing and free up the port. Also, adding time to the initialization sequence shouldn't drastically slow down the program as a whole since it is only running once at the very start. 

[rolfk]

What speaks against the approach to simply increase the VISA timeout during initialization (or simply use a longer timeout through out). The only drawback of a longer timeout is that if you want to detect that a device is not responsive, it will take the full timeout period to notice that. As long as the device (eventually) responds, a longer timeout doesn't hurt in any way.

[Vasilich2004]

I think it is wrong impression that error comes due Arduino initialization. When you see the error it means that Arduino device USB was hanged early (see my previous post about 2 commands with slow device in Arduino).

As I see LINX library opens serial port without error, writes into serial port and gets error that port is not accessible which is VISA serial port error. LINX convert VISA serial port error into 5001, after that into 5003. So -5003 error shows that Arduino device isn't accessible and it is becomes visible during initialization.

Delay helps to avoid this issue. It should be placed in each slow device to minimize impact.

[Vasilich2004]

did you load LINX program? did you check that LINX blink application work fine?

if yes, i would suggest power off-on arduino board. when you will run your program first time and will get 5003 error after open i2c then i don't know. if you would get 5003 error later in debug mode (which provide enough delay) then i don't know again. In another case you can play with delays. (I assume I2C commands are correct.)

[mamprat]

hello sir 

can you give an example tutorial how to fix it? I'm a confused by some of the existing tutorials. Thank you in advance

[ccwilliam]

With a clean community edition install, after uploading firmware to a mega 2560, the blink example will not work. Error 5003. The workaround DDuff posted is the best option. Main loop execution speed is not effected by this fix. Thanks!

[mamprat]

sorry sir i dont understand about your opinion, can you explain in more detail and simple? thanks in advance