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: 

two parallel DAQ while loop, one always getting slow when parallel running

Solved!
Go to solution

pop-up on the VI icon and choose properties >>> Execution.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 23
(2,047 Views)

The GetCurrent VI is marked as AboveNormalPriority and to use the instrument I/O execution system.  I would try lowering that priority to Normal since you don't want it dominating the processor.

0 Kudos
Message 12 of 23
(2,035 Views)

Thanks  to Ben and pauldavey.

Here is the GetCurrent VI now settings.  However this does not solve the problem: when XY Graph works, this "GetCurrent VI" loop gets slower and slower.

GetCurrent VI new setting.PNG

0 Kudos
Message 13 of 23
(2,021 Views)

Your Time(ms)-array will build pretty quick and can cause some issues after some minutes. The Ticktime should be enough, possibly with a Min/Max added.

The Spectrum graph will suffer the same issue as you're trying to update it 1000 times/sec and also need to reallocate the arrays several times/sec.

Do this little cleanup help some?

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 23
(2,010 Views)

Your Time(ms)-array will build pretty quick and can cause some issues after some minutes. The Ticktime should be enough, possibly with a Min/Max added.

The Spectrum graph will suffer the same issue as you're trying to update it 1000 times/sec and also need to reallocate the arrays several times/sec.

Do this little cleanup help some?

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 23
(2,009 Views)

Thanks.

I removed Time(ms)-Array, and tested your cleaned version. It seems still not good enough. The "GetCurrent" loops gets slow down to 60p/s.

 

LV2013sp1

WT

0 Kudos
Message 16 of 23
(2,001 Views)
Solution
Accepted by topic author weitong

Yeah, you need to decimate the data drawn on the graph also, after 1000s you'll have 1 million points to draw on something 800 pixels wide ... Use a Decimate (Single shot) with a factor 100 on the arrays before building the cluster. The shift registers should be the full data. You might also truncate the arrays to e.g. 10k length. You'll probably need both if you plan to do long time testing.

Something like this (excuse the sloppy code, i think you get the idea)
decimate.png

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 17 of 23
(1,995 Views)

@weitong wrote:

Thanks.

I removed Time(ms)-Array, and tested your cleaned version. It seems still not good enough. The "GetCurrent" loops gets slow down to 60p/s.

 

LV2013sp1

WT


The XY graph is set as "synchronous" by any chance?

 

60 Hz is the refresh rate of the display.

 

In addition to the suggest made by others, try putting the XY graph in a disable structure to see if the upate are the problem. If so the "Defer.FPUdat" property of the FP can be used to defer FP updates if set "True" before the update and then "False" after the update.

 

Flying blind,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 18 of 23
(1,987 Views)

@Ben  已写:

@weitong wrote:

Thanks.

I removed Time(ms)-Array, and tested your cleaned version. It seems still not good enough. The "GetCurrent" loops gets slow down to 60p/s.

 

LV2013sp1

WT


The XY graph is set as "synchronous" by any chance?

 

60 Hz is the refresh rate of the display.

 

In addition to the suggest made by others, try putting the XY graph in a disable structure to see if the upate are the problem. If so the "Defer.FPUdat" property of the FP can be used to defer FP updates if set "True" before the update and then "False" after the update.

 

Flying blind,

 

Ben


The XY graph "synchronous" is not checked.

If I put the XY graph in a disable structure,  the  loop2 (Get Current) keeps reading fast with a speed around 190p/s.

 

What is "Defer.FPUdat" property?  How to use it in my code?  Thanks.

 

LV2013sp1

WT

 

0 Kudos
Message 19 of 23
(1,973 Views)

@Yamaeda  已写:

Yeah, you need to decimate the data drawn on the graph also, after 1000s you'll have 1 million points to draw on something 800 pixels wide ... Use a Decimate (Single shot) with a factor 100 on the arrays before building the cluster. The shift registers should be the full data. You might also truncate the arrays to e.g. 10k length. You'll probably need both if you plan to do long time testing.

Something like this (excuse the sloppy code, i think you get the idea)
decimate.png

/Y


This seems to workaround. Thanks.

The XY graph redraws the whole data array every loop, that's why it gets slow.

Then, how to add a single point to a XY graph plot without redrawing previous points?

OR

How to let waveform chart plot X-Y pairs, (not uniformly distributed X)?

 

The question still puzzles me: since the number of points get larger and larger for XY-graph redrawing, why the XY-graph loop does not obviously get slow, and the GetCurrent loop gets slower and slower.

 

Message 20 of 23
(1,970 Views)