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: 

Serial Communication delay

I am curious... What is the measured delay?

Ray
Message 11 of 19
(1,234 Views)
I don't have the exact number, however I can say this.
When using hyperterminal and probing the pin with a scope the transition from low to high is instant. But when using LV, the transition has a delay which is visible to the eye. One can qualitatively judge that the transition in hyperterminal is quicker than LV.
0 Kudos
Message 12 of 19
(1,226 Views)
Taking a quick peek at your sample vi, I noticed the sample VI had a baud rate of 9600 and the parity was set to 0, whereas you said your PC was set for a parity of 1 and a baud of 56000.
********************************************
Amateur programmer for over 10 years!
********************************************
Message 13 of 19
(1,221 Views)
Is this the VI I gave you to demonstrate one method of reading a variable number of bytes? If all you're experiencing is a delay on the writes, eliminate the configure serial port on every iteration. It only needs to be done once of the very beginning of a program. This example also needs a little cleanup to handle the case when nothing is returned by the instrument and you get a timeout.
Message 14 of 19
(1,213 Views)
Hi Dennis,

This is the example you gave me. The config vi for the serial interface is only don't at the beginning of the program. It is set properly and runs nice. However their is a delay as I mentioned between hyperterminal and LV. What do you mean by cleanup?
0 Kudos
Message 15 of 19
(1,209 Views)
Just for grins, run this program once and then delete the config serial port. Run it again and see if there's a delay in your write.

What I mean by cleanup is that a case statement should be around the second while loop so that it doesn't execute at all if there's a timeout in the first while loop.
Message 16 of 19
(1,207 Views)
Hi Dennis,

I tried you experiment and still no change.
I am new at programming, so can I ask you what is the purpose of the tick clock?
0 Kudos
Message 17 of 19
(1,204 Views)
Hi Preitano,

The tick count function simply takes a reading from a system clock. In this program, it looks like these functions are being used to compare the time between different iterations of the loop that is waiting to see if bytes are at the port. If the difference between the tick count inside the while loop and the tick count that executes before the loop begins exceeds the timeout input, then the loop will stop.

In order to see more of why this program is running more slowly than hyperterminal, you could use the VI Profile option if you have the Professional edition of LabVIEW. Simply go to Tools, then Advanced..., and then select VI Profile. This allows you to see how much time was spent in each part of your code. If you do not have the Pro edition, then you may be able to do a makeshift version of the same functionality by using the tick count function. You can place the tick count function different places in your code, and compare the times between certain steps. However, this might affect the speed of execution of the code, so it is not the best way to do this.

John M
Applications Engineer
0 Kudos
Message 18 of 19
(1,278 Views)
Preitano,

The Tick Clock simply returns the value of the millisecond timer. In other words it is just counts in milliseconds. It is compared to an initial Tick Clock value because the Tick Clock will not necessarily start counting at 0.

As far as the delay you are experiencing, have you tried performing a loopback test with this VI? I didn't see any noticable delay when I tried it with loopback test.

Shawn B.
National Instruments
Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 19 of 19
(1,161 Views)