05-06-2024 06:20 AM
I have several devices that communicate through serial. I have them programmed as write-response. i.e. It only gives a response when you write a message to it. During testing I found that the round-trip time (RTT) wasn't stable, it oscillated randomly between 10 and 20 ms. Moreover, the RTT decreased when adding a delay. But only when the delay is implemented by placing the VISA write and read inside a Timeout Event case. When placing the write/read outside the event case, but still in the same loop, the oscillation returns. The same happens when using the Wait, Wait Until Next ms Multiple and High Resolution Polling Wait functions.
Here are the 2 setups, they should behave exactly the same.
Here the Serial Port setup
And the result. This test was done on a third-party device where I don't have access to the firmware source code.
It's very clear that the placing the write/read function inside the event structure both reduces the average RTT and makes it more stable.
Here is the same test done on a Raspberry Pi Pico.
I need the delay, because these devices are placed on the same RS485 bus and it is not necessary to read as fast a possible, it would only occupy the bus, so I need this delay, but the RTT should also be stable and as low as possible. Any suggestions?
Relevant software:
LabVIEW 2021 SP1
NI-VISA 21.5
Solved! Go to Solution.
05-06-2024 07:30 AM
Does your VISA device not use a EOL (CR, LF) as a terminator? Have you considered simply wiring a U8 13 (or 0x15) if you want a <CR>? I recommend using Wait (ms) instead of an Event Structure that consists of just a Timeout. I don't recognize the Vim you are using, but I assume it does some timing ...
If I had this problem, I'd add a Stall Vim following the VISA Read and make it, say, 10 ms to see if that lets the VISA communications "settle down". What does your documentation suggest?
Bob Schor
05-06-2024 07:50 AM
@Bob_Schor wrote:
Does your VISA device not use a EOL (CR, LF) as a terminator?
I've been testing my own protocol. This device uses a < as a start character and > as the end character. The third party does indeed use the CR (0x15) character. Sorry for the confusion.
@Bob_Schor wrote:
Have you considered simply wiring a U8 13 (or 0x15) if you want a <CR>?
Does that change anything? I find this easier than remembering hex codes for each termination character.
@Bob_Schor wrote:
I recommend using Wait (ms) instead of an Event Structure that consists of just a Timeout.
I know, so do I. But as I said, using the Wait gives the problem I've been having.
@Bob_Schor wrote:
I don't recognize the Vim you are using, but I assume it does some timing ...
Yes, it simply gets the time
@Bob_Schor wrote:
If I had this problem, I'd add a Stall Vim following the VISA Read and make it, say, 10 ms to see if that lets the VISA communications "settle down".
Well, that actually removes the big oscillations for some reason. So does forcing the wait to execute after the read (see below). I still don't understand why though. The interval between VISA write/read changes only be the RTT in the second case. Increasing the wait in the first case by the RTT should then also smooth it, if it is indeed the VISA settle time, but it still oscillates, even with 1000 ms wait
Left is erratic, right is consistent.
It's not a perfect solution to my problem though, I'd prefer if the VISA read is called a regular intervals, conjestion in the 485 bus may cause one read to take longer than others, increasing the total time before waiting fixed time.
05-07-2024 03:19 AM
Try exchanging the wait (ms) for wait until next ms multiple. Also, there is a little known setting on USB serial devices that can sometimes be set in Windows Device Manager. Look under advanced properties of the serial port and reduce the latency setting.
05-07-2024 03:37 AM
@MichaelS78 wrote:
Try exchanging the wait (ms) for wait until next ms multiple. Also, there is a little known setting on USB serial devices that can sometimes be set in Windows Device Manager. Look under advanced properties of the serial port and reduce the latency setting.
Reducing the Latency Timer works perfectly! Thank you so much, the speed is much higher now and the timing is stable, no more oscillations even when using the Wait function.