What is causing error 50202

[rick.s.murphy@thyssenkrupp.com]

 

After many hours (24-48 typically) of running, my application displays the error message shown above (error 50202).  The application sequentially fires outputs with NI 9485 modules and checks input voltage on a 9201 module, and then appends data to a text file.  The modules are installed on a cDAQ-9172 chassis.  A new text file is created every 12 hours.

When this error occurs, the computer seems to be running low on resources.  I could not launch windows explorer and wordpad simultaneously to grab the screen shot above.

The application was developed on Labview 10.  It is deployed on a Windows XP machine.

Any troubleshooting advice would be greatly appreciated.

[Christian Mergl]

Please have a look at this KB.

Christian

[rick.s.murphy@thyssenkrupp.com]

Thanks.  However, neither of those 2 findings apply to my situation.  I am using C Series data acquisition rather than E or M series.  I am also using an Intel P4 processor rather than an AMD processor.

Any other leads or troubleshooting techniques would be highly appreciated.

[JÞB]

Just a guess since you did not attach your code,  are you re-creating a DAQmx Task each time you use it?  This is poor practice and eventually causes this type of perfomance (memory leak) problem

[rick.s.murphy@thyssenkrupp.com]

No, I'm not recreating the task.  I have added attachments of my code.

I originally used the DAQ Assistant to build my acquisition code.  That was in a loop.  I then exploded that into various components and moved the sub-vi containing the create task outside the loop.

[rick.s.murphy@thyssenkrupp.com]

One more sub-vi is attached.

[RavensFan]

Where in your VI is this error being generated?

You have wires in there called Fail counters that have I32 indicators, but the wires seem to be a mix of blue (integer) and orange (floating point).  Logically they should be indicators, and since comparisons with floating point numbers can cause problems, I recommend fixing the code to convert all the wires to blue and eliminate the coercion dots.

How fast is your code running?  I don't see anything in your while loop that regulates the speed of your program.

Note, there are also =0 and >0 functions on the comparison palette, you can eliminate the zero constant and all the extra wiring by using them.

It is also a good idea to make your state machine enum a typedef, and use the typedef for all your constants.  That way if you later need to modify your state machine by adding another state, you don't have to replace or edit the dozens of state machine constants all over the VI.

[JÞB]

Raven's makes some good suggestions but,  I can't see an obvious source for the error- I thought about maybe the file size----but the error is not thrown from a sub.vi and nothing at the top level uses the error wire.  Its almost like some other service is leaking memory.

Oh, and break yourself of the habit of using bundle and unbundle-  use the "by name" versions to improve readability of the code- trust me you'll thank yourself .

[rick.s.murphy@thyssenkrupp.com]

Thanks for the good advice, Raven and Jeff.  I have attempted to make the changes you suggested and attached my latest code.

If anyone else has an idea for solving my error, I would appreciate any suggestions.

[RavensFan]

We still need to know where the error is being generated.  Try putting some probes on your various error wires to narrow it down.