LabVIEW
Labview random serial port Error -1073807339 VISA Read Timeout ARDUINO communication
Congratulations on a very nicely written and informative first post, complete with all of the useful things to help you.
Unfortunately I don't have LabVIEW 2018 installed, so I can't open your VIs, but here are my first thoughts...
My guess is that when you run the code as a subVI, it shares access to some I/O resources, possibly via the VISA driver, and so the loop is unable to keep up with the communication from the Arduino.
After a period of time that depends on how badly it's falling behind, the buffer overflows and then the Read Timeout occurs. It's not obvious to me that this is possible when my suggested hypothesis is that you're overflowing with data... so my next questions become: how large is your buffer, how many bytes are you attempting to read each iteration of the loop, and is it possible that a warning occurs regarding reading without emptying the buffer, but that this warning is overwritten by the error which occurs quickly afterwards? (These are all questions I could answer if I opened the code, so again my apologies)
It's certainly possible in principle to run loops faster than once every 4ms, but without seeing I can't guess what you might be able to change. The baud rate combined with message length make me feel like the time taken to receive the message should be something like maybe 70*8/115200 = 4.861111ms, which actually given I guessed the message length based on the components is pretty close to 4ms... Maybe it can't be faster.
Edit: This actually brings me to a separate question - how sure are you about the loop time on the Arduino, and are the sequential data sets independent (i.e it's not just spamming the same data?). I'd guess this uses the TCNT1 timer, but I'm going to have to google that now...
As a troubleshooting step, I'd suggest the following two possible modifications:
- Check the Bytes at Port value periodically during execution. If this number is continuously increasing, you'll eventually have buffer overflow (checking this will slow down your loop, making the problem worse, so don't leave it in if there is a problem)
- Make the buffer larger (Setting the Serial Port Buffer Size for Receiving or Transmitting Data with VISA) and see if the time to fail is longer. If you prefer to save time, make it smaller and see if it fails faster.
@perry_tiff wrote:
Regarding: This actually brings me to a separate question - how sure are you about the loop time on the Arduino, and are the sequential data sets independent (i.e it's not just spamming the same data?). I'd guess this uses the TCNT1 timer, but I'm going to have to google that now...
--> I am not sure if I understand that correctly, but yes I use the TCNT1 timer and the delay of the loop is 56.
I meant that I imagine you're using the value of the TCNT1 timer, via timer1_counter and the Serial.print to determine the rate of the loop. Is the value being printed 56?
You're using a 1024 multiplier with the clock rate - did you account for this in your determination of the loop rate (you seem to be careful, but better I ask a silly question than ignore the possibility).
Thank you for the screenshots. I'll look through them more carefully but I also don't see any problems at a first glance. Any warnings created at the VISA Read (for example due to remaining values in the buffer and a non-terminated read) wouldn't appear though - it will wait for an error to cause a stop, and warnings don't read as True when evaluated for a stop condition.
So I have a new "grasping at straws" hypothesis - I'm still not convinced that you can actually get data out of the Arduino faster than about 1 iteration every ~4ms, but reading the documentation for Serial.print (unlike Serial.write, it seems) informs me that Serial.print(..) is asynchronous and will return before transmission. This would definitely (at least initially) allow the Arduino loop to run much faster, filling the Arduino buffer.
Unfortunately, I'm not sure what happens at that point. It seems the write buffer might be just 64 Bytes (which I'd have guessed is less than your message length, but I'm not sure - probably close) and then Serial.write would block. I can't find out what buffer Serial.print uses though - perhaps it's willing to continuously increase usage of the SRAM until it runs out of memory (perhaps this takes 2-5 minutes? I haven't tried to calculate, and would need to know which Arduino you're using).
You can slow down the Arduino loop by using Serial.flush() at the end. This will block until the write buffer is emptied.
Possibly alternatively, you could switch from .print(..) to .write(..), but then you're writing binary byte arrays rather than ASCII strings (unless you pass a string), which might (precision-dependent, but likely?) reduce your data size with some care (increasing max speed) but would require more coding (mostly on LabVIEW side)
There's also a Serial.availableForWrite() function that returns the number of bytes that can be added to the write buffer, but as I said I'm not sure the location or size of the buffer used by Serial.print(..).
Edit: I should point out the reason why I'm "grasping at straws" here and not particularly confident is I have no idea why it would work happily in one case and not in the other regarding subVIs and main VIs.
You can also try enabling "Synchronous" reads on the LabVIEW side by right clicking the Read node - this will possibly mess with other parts of your program but the LabVIEW help tells me it produces the fastest throughput for that node. I've never used that setting, YMMV.
