09-29-2009 11:06 AM
03-26-2010 08:58 AM
04-20-2012 07:09 AM - edited 04-20-2012 07:09 AM
I am using the CDL in CompactRIO Temperature Controller Reference Application (http://zone.ni.com/devzone/cda/epd/p/id/6314) and find that it is leaking memory very quickly. Logging about 300 tags causes an additional ~30kB of RAM to be allocated for each call (once per second). Has anyone seen this?
(LabVIEW RT 2011 on multiple cRIO targets.)
05-24-2012 07:10 PM
The CDL API was written in LV 8.6 which used the TMDS 1.0 file format. In LV 2009 and later the TDMS file format 2.0 was released which among many things eliminated a memory leak that could occur on certain Real-Time systems. Opening the CDL Configure CVT Data Logger.vi that the CDL API ships with and changing the file format version input on the TDMS Open.vi from 1.0 to 2.0 and saving the change should fix the issue.
09-13-2012 06:35 AM
I guess I have found one issue or property with CDL. In my case I use CDL with a buffer of 200 samples/chan (Scans per Write=200). The reason I use rather large buffer is to avoid constant file I/O. Sampling rate is normally 10hz. For longer test runs we use 1Hz. The problem is that when I call "CDL Stop data Logger.vi" to stop logging, the buffer isn't flushed to file. Instead I lose the samples that are in the buffer because they are never written to the file after stop function has been called. With 1Hz sample rate it means I may lose ~200 seconds worth of data. So basically, if I want to make sure I get all the data, I have to wait at least 200 seconds after test run has completed before calling the stop function. The behaviour I would expect from the CDL logger is that when "CDL Stop Data Logger.vi" is called "CDL CVT Data Logger.vi" should stop immediately and flush the contents of the buffer to file.
Could you verify the behaviour I described or am I doing something wrong?
09-20-2012 09:07 AM - edited 09-20-2012 09:07 AM
Looking at the CDL code (version 2.0), the logger engine once it receives the Stop command is intended to finish buffering the current block of data, then send the buffer to another loop to write the data to file, and then stop the logger engine.
In your specific case this means that once you call Stop CDL Data Logger, it may take up to 20 seconds (10 Hz) or 200 seconds (1 Hz) for the
09-20-2012 11:25 AM - edited 09-20-2012 11:26 AM
(Unfortunately my previous reply was cutoff for some reason.)
Looking at the CDL code (version 2.0), the logger engine (CDL CVT Data Logger.vi) after receiving the Stop command through the front panel stop control, should finish buffering the current block of data, then send the buffers through queues to another loop to write the data to file, and then stop the logger engine.
In your specific case this means that once you call Stop CDL Data Logger, it may take up to 20 seconds (10 Hz) or 200 seconds (1 Hz) for the logging engine to actually stop as it is finishing the current block of data.
The CDL Stop Data Logger VI does have the ability to abort the logger engine mid-acquisition if the Abort parameter is set to True and the Timeout (default 2 seconds) for the engline to actually stop is exceeded. So in your case if Abort is set to True this may in fact stop the engine without flushing the rest fo the current buffer to disk.
Depending on how you setup your application, even if you don't have the Abort flag set to True, it may still be possible that all background processes (VIs) are aborted when you stop the rest of your application.
In order to flush the buffer to file immediately when the Stop command is sent, it will take a bit of redesigning in the logger engine. For this change the main (timed) loop would need to process 'stop' on every iteration (not just in the True case of the Logging Data case). If a stop is received the current buffer (arrays in shift registers) would be written to the queues and the current index in the buffer written to a new local variable. Then in the bottom loop (which takes the data from the queues and writes it to file) you would need to check the index value and only write the new data to file.