LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow loop iteration. Data acquired slower than the ideal logging frecuency.

Solved!
Go to solution
Highlighted

Good day,

 

First of all, thank you for taking the time to help.

 

I am writing a VI to provide control and data acquisition for an experiment.

The VI controls mass flow controllers and valves, plus reads thermocouples, pressure sensors, and other analog signals.

 

The VI is working, but I am trying to save data every 0.5 seconds. I am doing so using the "Write to Measurement File.vi" because it is easy to implement and has worked well enough. The problem I'm having is that the data is saved every 1.33 seconds, no matter the loop metronome's or wait time. 

 

Originally, I thought it could be the "Write to Measurement File.vi" slowing things down, but even if I remove this VI, the loop maintains this frequency/period. I would appreciate any help making the loop work faster (at least twice per second), so I can keep a higher frequency data log.

 

Thank you very much!

Sebastian. 

 

0 Kudos
Message 1 of 8
(378 Views)
Highlighted

What a mess!  You do realize, I presume, that your loop cannot run faster than the longest time it takes for data to pass through every tangled web inside there, correct?  

  • Where are the timing parameters for the top Analog Input loops?
  • Have you tried running that top Analog (messy) chain in isolation, all by itself, to see how quickly it can run?
  • Similar questions for the Analog Output and Digital Output chains.  Run them in isolation, measure their loop times.  I see no "timing" VIs in your DAQ sequence (but I might have lost them in the weeds ...).
  • If time and precision are concerns, try to avoid Express VIs, and especially the Dynamic Data Wire (black and white checkered wire).
  • Use Shift Registers instead of Local Variables Everywhere.  Saving constants in an Indicator and then using a Local Variable is sloppy LabVIEW coding.
  • Don't have wires zigzagging back and forth on your Block Diagram.  Try to keep data flowing left-to-right.  To the extent possible, every function should be on an Error Line.

Bob Schor

0 Kudos
Message 2 of 8
(367 Views)
Highlighted

Hi Bob,

Thanks for your reply.
I'm sorry for the mess. I had to delete chunks of the VI that relied on SubVI's to make the code a bit more "friendly" (if I can even say that ).

I do know that the loop will run as fast as the task insides. That's why I put no timing to see how quick it can run.

The analog input chain is the result of adding all the analog inputs into one task. As I understand, you cannot run more parallel AI tasks with one chassis (only one onboard clock). I will recheck this assumption.

I just now tested eliminating express VI's and DD Wires, the frequency stayed at 1.33 secs per loop. I will try now without local variables.

Finally, let's say that the analog/digital chains are the ones running slow. As it seems to be the case; Then what is it to do? Adding a sample clock task doesn't seem to solve the problem.

Thank you very much for your input. It's very appreciated.

Sebastian.

 

 

 

0 Kudos
Message 3 of 8
(359 Views)
Highlighted
Solution
Accepted by smsas

I haven't got a clue what you're trying to do in that top AI chain. If you want to do reliable continuous acquisition then you should set it up with timing for continuous acquisition. Why do you have a Stop for the task inside the loop? Please do follow Bob_Schor's advice and run that top chain in isolation. Also, consider refactoring your program into multiple loops. Look at Producer/Consumer examples.

0 Kudos
Message 4 of 8
(318 Views)
Highlighted

Hi John,

 

Thank you very much for your input.

Taking yours and Bob's inputs, I was able to solve the speed issue within the loop.

I kept the "Write To Measurement File Express VI" and could also keep the local variables.

 

It seems that the problem was (as Bob and you mentioned) with the analog input chain. I re-checked, and I can handle 3 AI tasks with my chassis. I created them again (separatedly) using the "Project Task" assistant. Now, in the VI, I only call the tasks (channel, timings, and other settings are configured with the assistant). 

 

Additionally, you spot another problem; I had the stop inside the loop, now I moved it outside. 

 

Regarding your suggestion on running a Producer/Consumer loop:

I agree that this may be more elegant, but I am not sure what are the advantages. Besides, I don't properly understand how you can sample and write at different frequencies using a queue. 

 

 

Thank you very much!

Sebastian.

 

0 Kudos
Message 5 of 8
(301 Views)
Highlighted
Solution
Accepted by smsas



@smsas wrote:

 

Taking yours and Bob's inputs, I was able to solve the speed issue within the loop.

I kept the "Write To Measurement File Express VI" and could also keep the local variables.

 


Please DO NOT keep the local variables. You are going to run into issues with this, if not in this program then in the next.I'm just trying to spare you some future headaches here as a been there done that programmer. 🙂

 


@smsas wrote:

 

It seems that the problem was (as Bob and you mentioned) with the analog input chain. I re-checked, and I can handle 3 AI tasks with my chassis. I created them again (separatedly) using the "Project Task" assistant. Now, in the VI, I only call the tasks (channel, timings, and other settings are configured with the assistant). 

 


Why do you need multiple tasks? One task should be sufficient. No sense in additional clutter on the screen. 

 


@smsas wrote:

 

Regarding your suggestion on running a Producer/Consumer loop:

I agree that this may be more elegant, but if you sample the data at the frequency you wish to write, I fail to see any advantage (with a lot of effort required). Besides, I don't properly understand how you can sample and write at different frequencies using a queue (unless you send the data to the queue using a case structure??). Well, I am definitely not a LabView advanced user, and so try to keep the code as simple as possible as long as it works. 

 


 

There are a number of advantages to decoupling your data acquisition and logging.First, it's actually a more simple approach as it allows you to more easily troubleshoot issues such as this. It makes it easier to make changes in the future (perhaps you want to wait until you have 3 values and then write, for instance). When I was talking about Producer/Consumer, though, I wasn't just talking about data acquisition and logging. Why not segregate your AO and digital signals?

Message 6 of 8
(288 Views)
Highlighted

Hi John,

I just got rid of the local variables and will follow the advice for all future programs.


Regarding the parallel loops, I will do that for the next iteration, as so far it works.
One question, though; if you don't use local variables, how you exchange information through parallel loops? Queue, channel writer, other?


Again, thank you very much for all your help.

Best,
Sebastian.

0 Kudos
Message 7 of 8
(236 Views)
Highlighted

@smsas wrote:

One question, though; if you don't use local variables, how you exchange information through parallel loops? Queue, channel writer, other?


Exactly!  And that's where they get their strength.  The Producer, doing the data acquisition (and needing to be properly timed) does not "waste time" doing analysis, opening/closing files, updating displays, etc., but passes the data asynchronously to another loop by using a Queue (which has some "elasticity" and can hold a few data samples if the Consumer needs a little extra time now and again) or an Asynchronous Channel Wire (the Stream Channel is ideal for this).

 

Bob Schor

Message 8 of 8
(231 Views)