[LabVIEW Tutorials] Programming an Arduino using LINX

[GreennRed]

Have you run this VI or VIs ever without a 5003 error? At what stage in the VI running does the error appear?

Will your VI run with equivalent Arduino IDE code? Just to ensure your hardware is good.

Is your Arduino USB cable connected directly to your USB port, no USB hub? Ensure no other USB devices are connected and try again.

Boot the PC, end task all background programs, hot plug the Arduino as the only USB connected device, launch your VI and see if error is still there.

Sounds like it could be conflicting with other hardware or software.

[DDuff]

Hi GreennRed, 

All of this was redone this morning to verify I didn't miss anything.

So far I have never been able to get any LINX VI to work. 

I uploaded the standard blink program from the Arduino IDE and did not have any issues. 

The Arduino is the only USB plugged into the laptop. It is a direct connection from the laptop to the Arduino. 

I booted the PC, ended all extra tasks, plugged in the USB, and luanched the VI. Still getting the 5003 error. 

I did notice that the COM port for the Arduino does not change if I change which USB port it is plugged into. I am not sure if that is normal operation or not.   

Thanks for the help.

[GreennRed]

I think the COM port number for a simulated port and is same no matter what USB port your Arduino is connected to. But it changes for another Arduino. I have 2 Unos, one is COM3, the other is COM4.

[SINC]

Hi DDuff,

Other than trying what has already been suggested above.

---

The firmware wizard completes with avrdude.ard.exe done. 

---

Can you confirm the LINX firmware is actually being successfully deployed?

Once you run the LINX wizard, check the output log for the avrdude programmer to see if it actually deployed the firmware, I am aware that it will just say done even if there are errors.

Alternatively you can upload the LINX firmware from the Arduino IDE and see if that solves it.

Also i know you said you tried different USB cables, but try to confirm the cables you're using actually have the data pins in them and they're not just for power.

[DDuff]

Hi Sin, 

I do not see any errors thrown in the log, but I will attach it below to see if you find anything I missed. 

I also seem to be having problems with the firmware wizard (maybe this is all part of the same issue?) 

• I will select the Arduino Mega on the first page
• select the correct Com port on the second page
• change the upload type to "Build with Arduino IDE" on the 3rd page
  • the path page will pop up

Firmware Base Path is set to the default ...LabView 2020\vi.lib\MakerHub\LINX\Firmware

Arduino Path is set to C:\Program Files(x86)\Arduino\libraries 

I click Save (I assume this is saving my path selections), then Generate 

There is a pop up that says Done! 

When I look in the examples and in \Arduino\libraries there are no new files copied over for me to upload.

If I change the Arduino Path to just \Arduino it will start a cmd box and start the Arduino IDE with a blank sketch and that is it 

I rechecked the cables and verified they have data pins. I also uploaded the blink example using the same cable and it uploaded with no problems. 

[SINC]

Hmm the firmware is being deployed, so no issues there.

The 5003 error is from a time-out between the Arduino and LabVIEW.

So if I had to make an educated guess, given the info you provided you most likely have a conflict on the COM port resulting in a time-out.

The easiest way to confirm this is, if you have access to another PC with LabVIEW 2020 Community edition (which has LINX by default) or LabVIEW with LINX installed and see if you can run an example VI.

That way you can at least work out if its a COM port issue or a board issue.

If you don't have access to another PC try to reset or change your COM port the arduino is connected to;

Otherwise, don't have any program that may use the COM port open while you're using LabVIEW i.e. Arduino IDE/Putty.

Try that and see how you go.

[DDuff]

Hi Sin, 

I changed the COM port for the Arduino and it still throws the 5003 error. 

I don't have access to another 2020 labview version, but I do have access to 2019. Unfortunately I am having problem installing the legacy LINX on it (I think there is a work program blocking the install from VIPM).  I was able to install LIFA (LabView interface for Arduino). Using that I was able to flash the LIFA firmware using the Arduino IDE (1.0.6) and load their test "Blink" program successfully.   That VI did not throw an error and worked as expected. 

As a test I updated the Arduino IDE to the most current software (1.8.13) and ran everything again. This time it failed with the 5003 error as well. After switching back to the 1.0.6 version of the IDE and reuploading the firmware it works again. 

I feel like the 2020 firmware wizard is missing something or there is an error that would be thrown in the Arduino IDE that is not showing in the Firmware wizard. When I try to generate the firmware and load it manually in the Arduino IDE(1.0.6) I run into the problem I described in the post above where it doesnt transfer any of the LINX files over to the Arduino Libraries folder. I have manually copied them over, but I am not sure what all should be there, so I am not sure if something is missing. 

[DDuff]

Progress has been made!

So I started deep diving into the LINX Blink.VI and found that if I have the Highlight Execution turned on then the Open Serial.VI would not throw the 5003 error. After some digging I found this was the path of the error

Open Serial -> Initialize -> Initialize Device -> Synchronize -> Send Command -> Wait for Packet-> Wait for bytes 

In Wait for Byte.VI it seems like the program is timing out before the Arduino has time to respond. This was causing it to pass a True argument into the  Wait for Packet.VI and changing the Timeout error to be thrown.  The TimeOut parameter can be set a few levels up in Synchronize.VI as a parameter for SendCommand.VI (default is set to 100ms). I attempted to adjust the Timeout to allow the Arduino more time to respond but it did not seem to have any affect. I was also worried about slowing down all of the sub vi's that the timeout was being passed too and causing more problems.  While poking around I noticed that Initialized Device.VI was passing an "Initialize" argument into one of its sub vi's (Packet Number.VI . Further inspections showed that it was being used to initalize a 0 into the argument for Packet Number upon startup. I added a 2000ms wait to process to give the Arduino a chance to get started and it seems like everything works now. Once it get past the initial startup it does not seem to have any issues. 

If anyone happens to have any better/easier fix or more information on this issue I would be interested in hearing about it. 

[SINC]

Hi DDuff,

Excellent find - coincidentally enough I just started looking into this exact same issue when running LINX over a virtual COM port (same 5003/cmd error).

However, I concluded that it was because I had the RX/TX pins connected to my ESP-01 when trying to run the code (see my previous post about Wi-Fi to Serial Bridges if you're interested).

As I noticed, if you run the LINX VI's on the Arduino and connect anything to the RX/TX pins the VI will timeout instantly.

Looking into the LINX firmware it looks like it is constantly monitoring the UART pins for commands.

I'll try this out and see if this helps get communications going over Wi-Fi though. 

Otherwise regarding LINX, I'm not exactly sure if NI/Digilent are maintaining/fixing bugs anymore.

In fact i'm not even sure what the difference is between the version they included in 2020 vs 2019, from what I have seen they have just updated the VI icons. 

[SINC]

LabVIEW Basics #9 - Serial Communication with an Arduino UNO over Wi-Fi (LINX Sucks)

The conclusion to will LINX work over Wi-Fi? Along with a tutorial of how to send and receive serial data from your Arduino UNO over Wi-Fi in LabVIEW, to toggle ON/OFF LEDs.

But I'm sure you will be able to come up with more exciting use cases, than turning LEDs on and off.