LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Read only stable when inside an Event structure with a timeout

Solved!
Go to solution

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. 

 

Basjong53_1-1714993816924.png         Basjong53_2-1714993856189.png

 

Here the Serial Port setup

Basjong53_7-1714994376310.png

 

And the result. This test was done on a third-party device where I don't have access to the firmware source code.

Basjong53_3-1714993917164.png

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.

 

Basjong53_4-1714994026630.png

 

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

0 Kudos
Message 1 of 5
(368 Views)

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

0 Kudos
Message 2 of 5
(336 Views)

@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

Basjong53_0-1714999278238.png

 


@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

 

Basjong53_1-1714999516358.pngBasjong53_2-1714999526277.png

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.

 

0 Kudos
Message 3 of 5
(326 Views)
Solution
Accepted by topic author Basjong53

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.

Message 4 of 5
(272 Views)

@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.

0 Kudos
Message 5 of 5
(267 Views)