LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

slow vi execution- data loss

I am sampling 6 channels @ 100/sec.  the screen refresh rate is slow and there is a 2-12sec gap between datasets.  the 'dataset' being determined by 'number of samples to read' in DAQ Assistant.  I started off with simple while loop, then tried parallel loops, timed loops.....  Having just started programming in LabView, I assume it is a simple issue that I am missing.  Also, the task manager doesn't indicate an issue with memory or processing in any code I have written.  I sure would like some pointers b/c, if I want to add bells and whistles, I need to have a good base.  I attached three vi's.  one is the simple while loop.  one is a one channel tester for ideas, and the last is what I got when I tried parallel loops with queues.  Mind you, I had four loops at one time. UI, DAQ, filtering, and file writer.  that worked ok, but nothing really has helped with performance, and I still get data loss.

Message 1 of 14
(3,400 Views)

Yep! You've got a few oddities in there!

 

First Express vis- They are not effecien and WORSE they obfuscate what you really meant to do with what they did.

 

DAQmx- basics.  Create your tasks once! those darn ExVI's are re-creating the same "task" on every iteration.  A better method is shown in the snippet below as a Queued Producer Consumer

EX.png

 

Next Those filters! moving average of 100 with only 10 points read per chanel ---- nope does not make sense and the ExVIs will output some funny stuff.  Then, you convert the waveform to a single point?  How about just taking the RMS of the data?

 

The formula nodes are totally unnecessary! you can (and do) apply a Scale to any channel in any DAQmx Task and rescaling after scaling is not just a little bit odd.

 

Some of the LabVIEW shipping examples will give you a bit more clarification.  Kudoes for taking the effort to try to find a way around your issue.  Not many posters try 3 times.  Just unfortunate that you missed the bigger cause.

 

 

 

 

 

 


"Should be" isn't "Is" -Jay
Message 2 of 14
(3,395 Views)

three times? that is just a summary of my effort.  Many hours has this non-programmer been spinning his wheels. I have only been working with LabView since Dec.  Really intensively only for about two weeks.  everything I know is self taught from forums and trial and error.  Of course its going to be a steaming pile of code! 

 

 

the DAQmx you use gave me a similar setup page to DAQasst, so I thought I could use them.  The filters, I figured they would do a rolling average ten iterations of DAQ.  I did have good front panel output of filters... played with the numbers. The formula nodes are necessary, well, almost.  I'll use math functions and constants to replace formula node.  Probably faster.  I am not rescaling, I am translating voltage to pressure.  Need to read psi. 

 

lessons:

1) initalize DAQ task ouside of loop - huge

2) RMS instead of filter? I'll try it  Voltage has 20-40mV noise that has to go

3) formula nodes going away- math nodes should be faster.

 

any issues with write to file?  any tricks?  like batching data in slower loop?

 

Thank you for your reply, I really appreciate the help.

 

-Tom

 

 

Message 3 of 14
(3,387 Views)

Sorry If I was too blunt.  A little about DAQmx

 

A task is a collection of channels, timing, triggering, scales and other properties.  In your case for this application you could create 1 task with 10 channels since all of your channels are AI nSample on demand.  You can mix chanels from multiple devices!

Dev1AI0 can have a scale (ch1_scale) that is linear Slope=3.0443 Intercept=0.0584 and scaled units = "PSI"

cDAQ1Mod1AI0 has a "built-in" scale for a pt thermistor- you applied that scale by selecting the RTD type.

 

The DAQ config assistant can be launced from a number of places.  I often use MAX to configure my tasks and test them as I build them.  After saving a task in MAX (with any scale I create) You can Drag the task from MAX to the Block Diagram of the VI you want to use it on!  Since the task is already saved and configured you don't need to re-create it in LabVIEW so you merely need to start it and stop it!  If you need to you can even let LabVIEW creat an example of how to use the task for you!

untitled.PNG

untitled2.PNGuntitled3.PNG

 

 

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 14
(3,376 Views)

I tried some things.  changed filter to avg 10 points.brought daq asst out of loop.  kept the assistant b/c I was having trouble creating a task with multiple measurement types.  it writes correctly, but I still have data loss.  I thought for sure reating the daq task out of the loop would have sped things up, but...  I used scaling in daq asst.  i was able to eliminate 2 channels when i write file.  moved write file back into consumer loop.  tried 1 sample on demand in a tmed loop, didn't work.  went back to 100Hz reading 10 at a time. anyway, this is what I got now.

Message 5 of 14
(3,362 Views)

Yup- data loss! would happen with that!  But were getting closer! the DAQmx stuff is much better!

 

Lets talk about queues and loops (since you're missing some finer points)

 

As configurered your lower loop will spin once after EVERY queue you have gets an element (since all the de-queue element primitives will wait indefinately for an element). After iteration 0 you pass the old data referance to the queues back into the de-queue elements.  The queue referance really needs to be on a Shift Register!  Tunnels are a rather large problem here.  You only need 1 queue with all the data you want to operate on.  that will prevent your BD from having bunches of duplicated functions.  Spliting the signals out and sending them into different queues is definately doing it  the hard way! 

 

Once you correctly wire the queue referances via shift registers (See the example I posted earlier) the loops should run better and you can get rid of those DBL local variables (update the terminals in the consumer loop)

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 14
(3,350 Views)

I'm going to work on it. in the meantime, I also noticed that my write to file vi is probably opening and closing avery iteration.  I'm thinking of building an array and dumping it at the end.  Don't know how to do it, but I have some sample code.  concerning the multiple queues, i read a post about it.  A person had trouble feeding two sources in and getting both out.  I guess I was trying to avoid that.

0 Kudos
Message 7 of 14
(3,343 Views)

just make the data type of the queue "array of signals" and merge all signals when you enqueueSmiley Wink


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 14
(3,338 Views)

This is killing me.  I tried shift registers, no filters, no local variables, i even put shift register on daq task, no change.  it's about as stripped down as possible.  the one thing I notices was that when I used a start and stop task on RTD daq, it didn't work, but the program was fast.  I am curious if 2 loops, one for each daq, is a good idea.  I just have a hard time believing I would have to that.  regardless, there is still a 2 sec lag between iterations.

Message 9 of 14
(3,307 Views)

Thats a LOT better!

 

and it sounds like its working exactly the way you programmed it!  (hint: both of your tasks are 200 samples at 100 hz (200Smp)/(100Samp/Sec)=2sec.  )

 

A note on mixing measurements in a single task.  The DAQ wizard lets you create a task with 1 type of measurement (voltage for example) and then opens the DAQ assistant. To mix measurement types create the task with 1 type then use the big blue + at the top of the DAQ assistant to Add chanels of a different type to the existing task.


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 14
(3,302 Views)