LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial communication issue

I'm having a strange issue with some serial communication that should be simple, but I am pulling out my hair on this one. I am sending data both to and from an arduino to my PC. 

Every 1 second the arduino sends a serial string that it's waiting to find the HMI at bootup until it finds it.

 

The behavior I am seeing is this:

If i disable serial reads, my top loop executes at almost exactly 500 ms.

If i enable serial reads with a serial timeout of 1000ms or more, my top loop executes at the timeout rate of the bottom loop (x-y indicator shows 1000 ms), but i receive data and display it in my read buffer indicator

If i enable serial reads, but I set a serial timeout of less than 1000ms, i never read serial data??

Both my read and writes are set up to be asynchronous I/O modes. Am i just completely missing something there?

If it matters, I also have somewhat of a frankensteined setup of a USB-B to micro USB cable from the arduino, then an adapter from micro USB to USB c, plugged into my PC .

 

My goal is essentially that i'm sending simulated serial data to my Arduino from my PC, while also just polling trace debug messages.

 

GregFreeman_1-1763055895007.png

 

0 Kudos
Message 1 of 6
(241 Views)

My immediate thought is that you have an interaction with trying to read and write the same port at the same time. Generally, it is best to have a single loop handle all of the interfaces for a single port.

 

A trick I would use here is to use the Bytes At Port property to see if a message has at least started to come in. If there are at least 1 byte in the port, do a read. If 0, do a wait or nothing (depending if you have another wait in the loop).



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
0 Kudos
Message 2 of 6
(208 Views)

I have tried in the same loop with no luck actually. That said, when I used bytes at port with the faster timeout in parallel it always returned 0. However, I wasn't using a case structure and delay now that I think about it (was just wiring bytes at port into bytes to read) so maybe I was starving the cpu.

 

I'll try a couple more things along these lines.

0 Kudos
Message 3 of 6
(202 Views)

Closing the loop on this one...PEBKAC error I believe....

I have no issues if i put a small delay at the beginning of my LabVIEW program (1 second or so). That makes me think i'm doing something to blast data at the Arduino before it's ready (or something to that effect, maybe some issue in my setup function) and it's causing issues. I'm sure I'll get the true root cause but this should unblock me for now.

0 Kudos
Message 4 of 6
(161 Views)

So after some research, clarification from ChatGPT, and a lot of fiddling, i think the issue is if i start blasting serial data at the Arduino in the window while the bootloader is waiting to see if something will be deployed (after a reset happens -- which seems to happen by default when serial communication is opened on on the main USB to UART port), it can put the UART hardware in a weird state and cause this. That's why a simple 1 second delay at the beginning of my LabVIEW code resolves it.

0 Kudos
Message 5 of 6
(152 Views)

Arduinos reset when the DTR line is set. Unfortunately LabVIEW visa sets this when opening the port and no matter if your first operation is to clear DTR it's too late. One solution is to physically disable the reset circuit on the Arduino. The other is to not use LabVIEW visa. I personally do the latter when interfacing with Arduinos using the LabVIEW .net functions to use the SerialPort class as a solution instead of LabVIEW visa with DtrEnable set to false:

 

https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport?view=net-9.0-pp 

 

Message 6 of 6
(134 Views)