LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Delays in timed loops / best design?

Hi everyone,
 
I have a piece of code I'm working on and have a reasonable working version but it has a few problems with it.
I have attached pictures so you can (hopefully) see what it does. - spread over 2 diagrams unfortunately due to size.
I'm  a bot of a novice at this so I'm looking for help / advice really.
 
My hardware setup is an NI-PXI-1031 crate containing an NI PXI-4071 DMM module and an NI PXI-6251 M series multifunction DAQ module linked to an SCB-68 connector box. I'm using labVIEW 8 on a winXP platform.
 
The code is meant to be a signal generator, continuously outputting a user-specified signal on an analogue output channel. Simultaneously it needs to read in data on ~ 10 analogue input channels and an NI Digital Multi Meter (possibly adding a second one of these soon too). There is a visual display of every channel on the front panel, and the incoming data has some compression done to it and is saved to an output file.
 
I've used mainly express VIs so far, I'm not sure if these are the most efficient way to do things? It's all currently taking place in a timed loop, so each iteration takes 4 seconds. In theory therefore the output data file should have a data entry every 4 seconds, and each channel's data is the average of one full second of data sampled at 400Hz from within that 4 second period of time.
 
The program needs to run for a very long time (certainly months possibly even of order a year or two) without stopping when the experiment is running. which is where the problem occurs. As far as I can tell the program is bug / crash free, BUT once it's been running for ~ 5 days the loop begins to experience a lag and the "loop finished late" light switches on. The net result being that my data ends up being spaced more than 4 seconds apart.
 
This seems unusual to me because when the program is in its early stages of operation the loop actually takes less than 4s, and delays itself to start the next loop on time. Is there any reason why the loop should begin to take longer as time goes by? Is this an inherent problem with my code? Or could it be that windows processes (anti-virus, win update etc.) could be using up memory periodically and causing delays?    
 
I'm also looking to add some features to the code, but I don't want to do so until I'm confident I have the timing issues sorted.
Ideally the sampling should be continuous, but I can't seem to make it do that, without making the loop over-run. Presently the sampling appears to consist of sampling for one second @ 400 Hz, then it spends the rest of the time in the 4s loop doing the analysis / compression and writing out that data.
 
Any ideas?
 
Many thanks
 
Download All
0 Kudos
Message 1 of 7
(3,301 Views)

Firstly, it is not clear why everything needs to be in a timed loop. Instead, do your acquisition and control hardware timed, then use a plain paralell loop to query the buffered data at leasure.

Things such as writing to files don't really belong in timed loops. 😉

  • What is the VI memory use over time?
  • Have you done any profiling?
  • How big do your data structures get? (For example your table?)
  • What is the history lenght of all your charts?

It is difficult to give more detailed advice without seeing the actual code.

0 Kudos
Message 2 of 7
(3,280 Views)

Ditto Christian's comments.

Although the plots can be goobling up memory the file writing is what will eventually kill you.

A producer consumer architecture can help but an ever growing file will evenually devour all available memory.

So switch to a client server architecture with an option to switch to a new file occationally.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 7
(3,272 Views)
Many thanks for your initial comments 🙂
 
I'll attach my code when I get back to work tomorrow. I appreciate all comments / criticisms. I don't even know what the architectures Ben is talking about are - I've used express VIs because I don't really know what I'm doing, I've just tried to piece something workable together using the examples in the getting started guide, which all had the VIs in while loops. I then switched from While to Timed loops in order to make sure my data was equally spaced.
 
I'm not sure how to do a parallel loop. But hopefully with the tips so far I'll be on the right track.  
  • What is the VI memory use over time?

Not sure, how do I find out?

  • Have you done any profiling?

No, I don't even know what this is (I'm a novice)

  • How big do your data structures get? (For example your table?)

The table will grow and grow indefinitely as far as I'm aware. But it's not essential, it's just there as a visual guide to the user at this stage. I can easily lose this feature.

  • What is the history lenght of all your charts?

About 2 hours I think

Many thanks

 

0 Kudos
Message 4 of 7
(3,270 Views)

"I don't even know what the architectures Ben is talking about are -"

This link should explain what I was talking about.

https://www.ni.com/en/support/documentation/supplemental/21/producer-consumer-architecture-in-labvie...

Don't worry, I even confuse myself when I am working fast. Smiley Mad

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 7
(3,263 Views)


@Anti-Neutrino wrote:
  • What is the VI memory use over time?

Not sure, how do I find out?


"Menu...file...VI properties...Memory Usage"


  • Have you done any profiling?

No, I don't even know what this is (I'm a novice)


"Tools...advanced...profile VIs" In LabVIEW 7.x.

"Tools...Profile..Performance and Memory..." In LabVIEW 8.0


  • How big do your data structures get? (For example your table?)

The table will grow and grow indefinitely as far as I'm aware. But it's not essential, it's just there as a visual guide to the user at this stage. I can easily lose this feature.


OK, loose the table and see if it make a difference 🙂 Nothing can grow infinitely without hitting a ceiling at one point. Maybe you could just keep the last hundred points or so.

Can you run it a bit faster to quickly demonstrate the problem?

0 Kudos
Message 6 of 7
(3,247 Views)

Hi guys,

Thanks for all the tips so far. I suspect ditching the table will rectify the problem, along with making the "write to file" VI write to a new file every day rather than one just growing and growing... But I'd like to implement the new architecture anyway, so that the program can be added to and improved at a later date so tips are still wlecome.

I'll do a bit of profiling and analyse the memory usage and see what it says. 

I've attached the VI as it stands at the moment. I don't think there's a way to make it run any faster to demonstrate the problem. But feel free to take a peek, I'm probably making all kinds of horrendous errors, and if I am I'd like to know about them 🙂

Many thanks

0 Kudos
Message 7 of 7
(3,224 Views)