ni.com is currently undergoing scheduled maintenance.

Some services may be unavailable at this time. Please contact us for help or try again later.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

While Loop is very slow for serial reading

Solved!
Go to solution

@Norick17 wrote:


 The question is HOW I can improve my vi to solve the problem.


You have been told by three users that this is not a good idea. You have been given a link to a presentation that will help you improve your serial communication that you just proved you did not watch.

 

I doubt that you woke up this morning and decided to take timing measurements of a serial communication out of pure personal pleasure. Your motivation to do so is not irrelevant. In fact, it is the most important thing to tell us to provide any useful help.

 

In fact, what you are trying to do might just be utterly impossible.

0 Kudos
Message 11 of 26
(2,401 Views)

The timing pattern looks mostly similar to this one here, probably for the same reason -- quantization.  Hard to guess where it's coming from, though I wouldn't rule out the possibility that's it's down in the VISA / serial drivers.   We regularly see similar timing fluctuations for receiving lines of serial data when reading from a serial device that definitely writes at a constant clock rate.

 

Meanwhile, it will help if you provide more clarifying info.  The code you posted puts a single scalar measure of dt into an indicator named TimeArray.  The graph you post has units of Hz.  You talk about measuring time with a scope -- is it a protocol analyzer?  Else, what's the signal you feed to the scope to get time or frequency measurements?   There are a lot of unknowns because you haven't filled in the blanks for us enough.

 

 

-Kevin P

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 12 of 26
(2,395 Views)

@pincpanter wrote:

Serial reading is not appropriate for precise timing. Remark however that the average frequency is about 10.05 as expected.

Thus not only the lower values are wrong, but the higher are (less) wrong too.


although the average of about 10.5 is ok, the problem are still the values at about 9 Hz. What also is strange that it looks like a constant pattern which is not seen when measuring with a scope. Therefore it looks for me the problem is the vi itself or HOW to read correctly the serial data stream.

0 Kudos
Message 13 of 26
(2,391 Views)

@Norick17 wrote:


You are asking about "why" but this is absolutely irrelevant for my problem (question), because I need to know the timestamp between the "<" chars. It does not matter if it is 1, 3 or 10Hz.. The question is HOW I can improve my vi to solve the problem.


You could try this 

snip.png

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
Message 14 of 26
(2,381 Views)

Sure the vi is not optimized. If you switch to the term char technique, it's important to get the timestamp after the VISA Read.

You don't really need two loops. Use only one loop and store the previous timestamp in a shift register: you will also spare half of the timestamp readings.

EDIT: as shown by Jay14159265

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 15 of 26
(2,372 Views)
Solution
Accepted by topic author Norick17

Is this by any chance a USB serial converter? Ftdi and other converters have a polling rate settable in device manager which is 16mS by default. I have dropped this to 1ms before to solve a similar issue.

Message 16 of 26
(2,324 Views)

@pincpanter wrote:

Sure the vi is not optimized. If you switch to the term char technique, it's important to get the timestamp after the VISA Read.

You don't really need two loops. Use only one loop and store the previous timestamp in a shift register: you will also spare half of the timestamp readings.

EDIT: as shown by Jay14159265


This makes sense to get the timestamp after the reading. I used the proposed vi from  Jay14159265 although I could not import the code shared. Therefore I attached my current vi. 

The outer loop is only for stopping the reading in my case (blue).

 

new read.png

The reading for this vi with 5 Hz looks like this now:

Read 5Hz.png

 

I verified this reading in parallel with a logic analyzer which runs at 500 MHz. This shows for all readings 5 Hz +/- 1% accuracy.

0 Kudos
Message 17 of 26
(2,300 Views)

You have set up a termination character AND read one byte at a time. If you are reading one byte at a time, termination character setup is of no use anyway. I still suggest you make use of the termination character and read enough bytes to catch that instead. Reading one byte at a time is not very efficient.

 

Certified LabVIEW Architect
Message 18 of 26
(2,295 Views)

you are right reading one char is not the best. So when using outside the termination char and reading about 25 chars at once, how to I set the timestamp in following vi?

 

newvi.png

 

Would you suggest to search in the string of 25 chars and check for the ">" char?

0 Kudos
Message 19 of 26
(2,282 Views)

When you set a term char, the VISA Read outputs a timeout error if this char is not there.

As I already suggested, require a large number of characters (e.g. 1000), then check for the error output. If there is no error, you are sure that the term char is there.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 20 of 26
(2,279 Views)