LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Arduino UART communication from LabVIEW

Hi,

I have an Arduino Mega 2560 connected to a device using Arduino's serial port 1 (UART) and I am trying to make a LabVIEW test VI with LINX functions.

Using LabVIEW 2014 and LINX 1.0.0.59.

I've already tested the connection by programming in Arduino and it's working. I can send commands to the device and it's answering propoerly.

 

From the VI (attached), I wanted to send to the UART the string "M\r\n", which means the bytes 77, 13 and 10.

The device is not answering, the number of available bytes is zero.

 

I've made two tests, one connecting together the RX and TX lines on the Arduino's UART port, the second connecting a serial port of my computer instead of the device.

 

In both cases, it seems that the data which is going out from the Arduino's UART port is not made of the bytes 77, 13 and 10, but is the string "771310" (bytes 55, 55, 49, 51, 49, 48)

 

I've looked in the "UART Write.vi" from LINX and everything seems right there, so the only idea I have now is that the problem is in the LINX firmware.

 

Did anybody encountered the same problem ?

 

Thanks a lot,

Tom

0 Kudos
Message 1 of 3
(5,451 Views)

I can't see your code, since there is so much missing for me.

 

But basically, if you are getting "771310" instead of "\77\13\10" then you are using the wrong function to convert for sending.

 

If you used CONVERT TO HEX STRING, with an array of [\77, \13, \10] you would get the results you're seeing.

 

If you have the array [\77, \13, \10]  then you want to avoid all conversions - send it as it is.

 

Screen Shot 2016-05-24 at 6.43.00 AM.png

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 3
(5,410 Views)

Hi Steve,

Thanks a lot for your message.

Here is the picture.

UART Test.jpg

 

I am converting the "M\r\n" string to an array of bytes: 77, 13 and 10, and then I am receiving the "771310" string.

The 77, 13 and 10 bytes are in decimal, not hex.

 

Tom

 

0 Kudos
Message 3 of 3
(5,403 Views)