LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQmax Start Task Error -200022

Hi Jose,

 

Could you open up Measurement & Automation Exploler and make sure that the device you are trying to use in LabVIEW is listed under Devices and Interfaces. Feel free to post a screenshot of your MAX window. If your device is listed under devices and interfaces, right click on it and select Test Panels. Then select the channel you are trying to read in LabVIEW and make sure you can read a signal on that channel.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 11 of 20
(1,013 Views)

Sev

 

I've checked the devices in Measurements and Automation Explorer they are all there and working. Also, the program run OK for a couple of hours, but after a while it gets very slow. That's when I get the cDAQmax error and my displays don't concur with our system. For example, if by mid day the program is measuring 2 to 3 kW of solar power, at sun set the program is still displaying between 2-3 kW as if that was the actual data acquired. We can even turn off our system and it still displays the same data. Also, in our log data it can be seen that it starts acquiring data each second, but when the program becomes slow it starts acquiring data every 3 - 4 seconds..

 

I know our program is really heavy, but we've increased the RAMs of our computer so I know that the computer can handle the size of the program. And it's been discussed that we want to add more stuff to the VI in the future. Is there a way that I can make sure the cDAQmax is not running out of memory or that it uses little memory to acquire the data?

 

Thanks,

 

Jose

0 Kudos
Message 12 of 20
(1,008 Views)

Hi,

 

I looks like you might be running out of memory during the execution of your VI. Check how much memory your VI uses by going to File>>VI Properties>> Memory Usage. Also I suggest running the performance analyser tool while you run your VI. It is located under Tools>>Profile>>Performance and memory.Start it before running the VI and stop it right after the VI stops. It would be helpful if you post screenshots of these (memory and performance analyser) windows or provide some feedback on what you see when you run the performance analyser tool.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 13 of 20
(1,000 Views)

Ok,

 

Here is a detailed description of the errors according to the VI:

 

Error -200279 occurred at  : DAQmx Read (Analog 1D Wfm NChan NSamp).vi:1    Possible reason(s):   Attempted to read samples that are no longer available. The requested sample was previously available- but has since been overwritten.  Increasing the buffer size- reading the data more frequently- or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.   Property: RelativeTo Corresponding Value: Current Read Position Property: Offset Corresponding Value: 0  Task Name: _unnamedTask<3>
Error  -200361  Error -200361 occurred at  : DAQmx Read (Digital 1D Wfm NChan NSamp).vi:1    Possible reason(s):   Onboard device memory overflow. Because of system and/or bus-bandwidth limitations- the driver could not read data from the device fast enough to keep up with the device throughput.  Reduce the sample rate- or reduce the number of programs your computer is executing concurrently.   Task Name: _unnamedTask<2>

 

Also, I'm attaching a power point presentation that shows how the VI was behaving after a couple of hours of data acquisition.

 

Thanks

 

Jose

 

0 Kudos
Message 14 of 20
(992 Views)

Hi Jose,

 

Are you doing any data processing in your data aquisition loop? If you are, that might slow down the data aquisition loop so that it cannot keep up with the required sampling rate and is not able to read all the samples from the buffer. I would suggest adding an indicator that monitors the number of samples in your buffer and check if that number keeps growing as you run your VI. See the following KB for more details on how you can monitor the number of samples available in the buffer.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 15 of 20
(979 Views)

Hello,

 

I used the DAQmx read property node and selected Available Samples per Channel as suggested in http://digital.ni.com/public.nsf/allkb/AB7D4CA85967804586257380006F0E62?OpenDocument. It ran all night without giving me the error -200279; however, it is still getting very slow. I was monitoring the number of samples per channel and in the morning it appeared to be 50-51. But, like I mentioned before, the VI tends to display data that does not concur with the actual data in the system. Sometimes it appears as if it was stuck in a loop displaying old data. Therefore, I don't know if the 50-51 samples per channel that I displayed is the actual number of samples available of if its stuck. At this point I'm not most concern on the speed of the program, but getting accurate that is critical. So any ideas or suggestions, please let me know.

 

Thanks again for all the help,

 

Jose

0 Kudos
Message 16 of 20
(971 Views)

Hi Jose,

 

Could you tell me what hardware are you using and also could you post a screenshot of your data aquisiting loop.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 17 of 20
(954 Views)

Sev,

 

I made a power point presentation showing the screen show of the VI. In these shots you can see the number of samples available (upper right side. I circles these in red just in case). Also, you can see the pop up window that shows the error message. For each screen shot I had an error message, and there where more error messages for different amounts of available samples from 0-1231. This made me think that even though the message says that there aren't sufficient samples to read, the problem must be due to something else.

 

P.S.. I also have attached an image of the hardware that we are using.

 

Thanks,

 

Jose

 

 

Download All
0 Kudos
Message 18 of 20
(941 Views)

Hi Jose,

 

The 9172 CompactDAQ chassis contains one System Timing Controller which has one Analog Input timing engine. This requires chassis containing different analog input modules to all be configured with one common analog input task which results in one sample clock rate. With slow sampling modules, if the sampling rate of a hardware-timed acquisition exceeds the maximum sampling rate of the module, they will return the same data repeatedly until a new conversion on the slower modules completes (no warning or error is generated). This provides for flexibility when mixing modules in chassis. More details regarding multi-module configurations can be found in the followings links (1,2).

 

The slower modules (DC modules) repeat their samples until a new conversion takes place. For example, if running an AI task at 1 kHz using a module with a maximum rate of 10 Hz, the slow module returns 100 samples of the first point, followed by 100 samples of the second point, etc. Other modules in the task will return 1,000 new data points per second, which is normal. These repeated samples are data points that are sent by the module, not merely duplicated by the driver in the software layer. This is important because each one of these repeated data points is actual data that passes through the 9172 FIFO and ultimately the Universal Serial Bus. Essentially this means that a slow sampling DC module will use, at a minimum, as much bus bandwidth as a higher speed module in the same task.

 

Since many of the slow sampling DC modules have 24bit ADC's, each sample is represented with 4 bytes as opposed to a 16bit module representing each sample with 2 bytes. This means that for a fast 4 channel 16bit module and a slow 4 channel 24bit module operating within the same task, the 4 channel 24bit module will take up more bandwidth even though it can only create new data at a fraction of the rate of the faster module.

The increased bandwidth the 24bit modules uses when paired with a fast 16bit modules needs to be considered because of USB 2.0's bandwidth specifications. It is possible to create a situation where the USB bandwidth is exceeded due to slow sampling modules running at a high rate. In this case, "error -200361: Onboard device memory overflow." is possible because the bus can't stream data from the onboard FIFO fast enough, causing the FIFO to overflow. Thus, I would suggest decreasing the sampling rate of DAQmx task to the level which is compatible with slowest module in your system, which is 9217.


 


Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 19 of 20
(928 Views)

Hey Sev.,

 

I checked the sample rate for the 9217, and it can go up to 400S/s. By default the sampling rate was set to 500, I have decreased it before to about 200 and still got the same results. Now, I have it at 24 S/s and I haven't gotten any errors, but there is quite a delay between the monitoring equipment and labview. I think it's about 30 seconds to a minute, but I'm afraid that this might increase throughout the day. 

 

Is there a chance that can leave it at 400S/s, and not get error -200361?

 

Thanks,

 

Jose

0 Kudos
Message 20 of 20
(917 Views)