My system gets weird at loop count ~2050

[Scrx]

I have a labview system acquiring data in a 'while' loop, and between loop count 2000 and 2100 it gets weird.  Specifically: 

System is WinXP, Labview 7.1, PCI-6143 DAQ

I'm acquiring a sine&cosine wave (64 samples per sine, roughly 10Hz (slow! But I will have to go faster soon)) and an asynchronous square wave about 400Hz faster.  I want to count edges on the square wave between zero crossings of the sine wave.  It's wonderfully consistent up to about cycle 2050 in my while loop (equal to 2050 sine wave cycles), then it goes haywire, recording really ridiculous values high and low, getting steadily worse as the time passes.  I need to measure 9000 cycles.    

It is scarily repeatable.  Happens every time, and there is no control at all over the inputs that could cause such deviation. 

I am using Ctr. 0 to count square waves, and analog inputs to acquire the sine/cosine wave. 

 Any ideas?  I'm thinking it's because the card is running out of RAM, and the time delay involved in shifting blocks of memory around the PC screws up the loop timing.  The PC is doing nothing else (it's dedicated) although is probably running all the usual XP background stuff.  It's a Dell Core Duo at about 2GHz with half a GB of RAM.

 See the attached PDF, specifically the 'Absolute Error Log' graph.  The only reason this test 'passed' is because I input a really silly value for 'Abs Err Limit' - It should be about eight, not twelve hundred and eight.

 Thanks, Scrx 

[Hillman]

Hi Scrx,

Thanks for the post and I hope your well today.

I have seen loop count issues previously regarding the process within the loop taking too long.

I will look into this some more tomorrow morning (When the UK Office is open) if you could post your vi?

*edit:

Generally regarding memory usage you could try using the VI Anyliser (Tools>>VI Profilier..) and the  Show Buffer Allocations (Tools>>Profile) to see areas of extra memory created. Particularly if your dealing with arrays, make sure you initalize the array and then just shift the array around the loop to update its values. I would also recommend to be careful with the use of any variables. And my last tip - are you doing any writng to file? I would make sure your closing of any references to such tasks. All of these would cause (could cause) memory issues (leaks). 

Kind Regards,  

Message Edited by Hillman on 11-05-2008 08:08 PM

Message Edited by Hillman on 11-05-2008 08:10 PM

[RavensFan]

Thanks for posting the screenshot of the front panel.  But what is it supposed to tell us?  We don't know your application so "Pass", "Fail", and "Absolute Error Limit" doesn't mean anything to us.  Are you getting an error message?  If so, what is the error number and message description.  Exactly what is going wrong that tells you that you have a problem.

I would recommend you look at your code.  Are you building arrays continuously?  Arrays that grow in time will cause memory fragmentation and will take time as the arrays give shuffled around in memory.

Are you opening any references such as DAQ tasks or file references repeatedly, but not closing them?  These would eat up memory as well.

Posting your VI would be a bigger help to debug your problem.

[Scrx]

Hello both of you, and thanks again for very prompt responses.  I tried to post my VI once, but I think space aliens ate it (I'm using satellite internet here, so that's not so farfecthed!)

[Scrx]

PS - VI posting worked the 2nd time.  S.

[Scrx]

PPS - Moving the whole system to another computer just made it worse.  The noise still starts at about cycle 2050, but at about cycle 6400, it really goes apes---.  Off the scale.  S.

[RavensFan]

I think your problem may be in the Build XY graphs. I see the settings are for them to never be cleared.  Down deep in their subVI's, they are continually building data on  arrays.

I would recommend getting away from all the Express VI's.  Particularly on the Build XY Graphs for the reasons stated above, but also on the DAQ assistants.  Express VI's are great for quickly getting some code up and running.  But they don't scale well.  If you right click on an Express VI and select Open front panel (save a copy of your VI first because you can't undo this operation), it will create a subVI you can open and see the underlying code you can learn from and improve upon.

It looks like you are a new user to LabVIEW.  I would highly recommend taking the Basic LabVIEW courses from NI if you haven't taken them yet.  I would also recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours.

Also, in the first loop, put a small wait for ms statement in the loop for a couple hundred milliseconds so it doesn't consume 100% of the CPU resources waiting for the stop buttons and constantly checking the input values.

[Scrx]

Hi Ravens Fan

You're right, I'm a newbie at this (was it really that obvious?) but part of the point of using the XY Graphs is that they don't clear every time they're called.  And I can set that behaviour.  We're trying to log lots and lots of cycles, and even in the Lissajous diagram I want to see all the cycles overlaid upon each other.

And I see your point in re. the 'greedy loop' at the outset, but it's a dedicated computer.  I don't really care if it goes to 100% CPU trying to service this - It's what it's supposed to do.  Anyhow, I'll throw in a 10ms delay or something.

Thanks for your input!  I'll look into the courses.

 Scrx

[altenbach]

If you only want to plot a finite history (e.g. last 1000 points seen), you could also use the "collector" express VI and collect your x and y data before plotting.

Did you ever calculate how much data you're generating?

Yes, you first loop consumes 100% of the CPU and you should care. It actually reduces the responsiveness to user input while consuming 100% of the CPU. Ideally, you would use an event structure and spin the loop only if needed. Maybe later you want to run several similar programs at the same time.

There are also much better ways to check for validity. For example there is are "empty string?" and "not equal zero?" primitives in the comparison palette. You can use a "compound arithmetic" node in mode=AND to replace all your scattered "boolean AND" primitives. (See image)

Your last while loop has no purpose at all.

Instead of this long sequence of frames, you should look into a state machine.

Memory is not finite, and plotting Gigabytes of xy data on a finite area is just silly. You could use an intensity graph or picture indicator to map your data points into. This way the memory used is purely determined by the pixel size of the image/graph and you can really go on forever, or until the entire graph is colord differently. 🙂

Have a look at this old example (MemoryGraph04.vi) that draws on an intensity graph (original thread). Your problem is even simpler, because you only use a single z value.

Message Edited by altenbach on 11-05-2008 03:02 PM

[Scrx]

Hi Altenbach,

I did calculate the data required - 9000 cycles, sampled 64x, at 16 bits, is not two megabytes.  I've got computers with RAM measured in gigabytes.  I don't see the problem here. 

 You're right, I do want to plot a finite history (all 9000x64 points seen).  But I want the graph to build over time, so the operator can watch it.  Just scraping up the data and dumping it later on won't do.

The answer might very well be a 'picture' indicator.    

 What I'd really like for the input data validation is a bazillion-input AND gate.  Are there any LabView gates with more than two inputs?  

Anyhow, that part works fine.  It's not the user input that's the problem.

 The last while loop does nothing because I want it to conditionally print or reset based on user interaction.  But I can't find out how (I started another thread on this) to print the front panel on completion based on a user input.  I can do it with a menu item, but how can I wire a menu item to a LabView control?

Scrx