From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Pulling serial data from Arduino, running into problems

Solved!
Go to solution

I'm very new to Labview and I'm looking for some insight into an error here.

 

I have an Arduino running some very simple code that pulls some measurements off of a pair of devices and stores the latest values. When sent a query from my Labview VI it responds with the requested data, pressure data for a '1' and flow data for a '2'. I need to make sure that I first request data, then wait for the whole 4 byte float to arrive before reading and plotting.

 

Right now I have the block diagram organized by having the Serial write function send the query, then I sit in a while loop delaying until 4 bytes of data have arrived before reading the data, processing, and graphing. I do this twice per loop, once for the flow data and once for pressure.

 

The problem I have is that unless I add a significant delay into the "wait for data arrived" loops (wait for at least 10-20 ms) I sometimes get a zero being sent to the graph. I'm assuming that the read function is trying to read before the arduino has actually responded, but I'm not sure why adding a delay into those loops is necessary, or why it needs to be so long. Honestly I'm not at all sure the way I'm doing it is right at all, and I'd really appreciate any correction or advice from someone who actually knows what's going on.

 

I'm not allowed to attach .ino files but I can give the arduino code if needed.

0 Kudos
Message 1 of 7
(1,534 Views)
Solution
Accepted by Tarnarmour

Hi Tarnarmour,

when do people learn to NOT use BytesAtPort?

 

Simplified:

Are you sure you receive exactly 4 bytes from your Arduino? Then you should NOT use ConvertStringToFloat, but DeserialiseString (with its option to set byte order as needed)!

When receiving "binary" data you should also TURN OFF the TermChar…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 7
(1,525 Views)
Solution
Accepted by Tarnarmour

A generally suggested alternative to what you're doing would be to use Termination Characters, a large number of "Bytes to Read" >> length (4), and then a long(ish) timout.

 

The typical termination characters would be CR or LF (Carriage Return, Line Feed), and you can use Serial.println(myValue) on Arduino to append a CR/LF pair automatically (LF is the default Term Char in LabVIEW's VISA Configure Serial Port).

Take care to handle the extra CR that appears on the end (consider e.g. Trim Whitespace or similar).

 

Then you don't need to handle the waiting, the polling or the missing messages - everything becomes simpler.

 

See also Crossrulz's presentation from VI Week about this (and similar topics): Proper way to communicate over serial.


GCentral
Message 3 of 7
(1,521 Views)

As a separate problem, I'm also seeing your inner loops using "Bytes at Port" != 4 as the stop condition. That presumably isn't what you want... (although as already mentioned, there are better approaches than using Bytes At Port, especially if you control both ends of the communication (Arduino + LabVIEW code)).

cbutcher_0-1600188277444.png

 


GCentral
0 Kudos
Message 4 of 7
(1,516 Views)

@GerdW wrote:

when do people learn to NOT use BytesAtPort?


Probably when NI fixes their examples...but that is a fight I have had for a long time.  That was one of my reasons for the VI Week presentation (VIWeek 2020/Proper way to communicate over serial).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 7
(1,504 Views)

Wow, thanks a ton. That looks so much nicer than what I had. This is just what I was worried about, I was doing this in some horribly over-complicated and bad way. Ah well, that's learning I suppose. Thanks again for the swift reply, I really haven't loved the tutorials or docs by NI so far but this forum seems like it more than makes up for it.

0 Kudos
Message 6 of 7
(1,481 Views)

Well this is a very timely video to discover, much appreciated

0 Kudos
Message 7 of 7
(1,480 Views)