LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory Overflow cDAQ 9174

Solved!
Go to solution

I running into an error (-200361) when I run my state diagram using a cDAQ 9174 chassis.  I have a 9214 is slot 1, a 9237 in slot 2 and, 9207 in slot 4.  I have tried a couple of workarounds to get this VI to work, but I have not yet been able to figure it out.  I have a hard time believing this is hardware related and am thoroughly convinced it is because of the way I have wired this VI together.  I have looked at all the links provided in all of the responses I could find to similar problems without resolution.  What data is being written so fast that the processor is unable to keep up?  See the attached VI.

0 Kudos
Message 1 of 15
(3,086 Views)

How fast are you sampling? When you try and slow down the sampling rate do you still experience this issue? Also, your VI was not attached to your post. 

 

Corey C

Applications Engineer

National Instruments 

0 Kudos
Message 2 of 15
(3,033 Views)

I slowed my sample rate down to 1Hz, and still received the error.  When I click add attachment the page refreshes, but does not attach.  Is this a settings issue on my end or is NI website experiencing some issues.

0 Kudos
Message 3 of 15
(3,014 Views)

Make sure you don't have compatibility mode turned on in your browser.

0 Kudos
Message 4 of 15
(3,005 Views)

Settings fixed.  See attached,

Download All
0 Kudos
Message 5 of 15
(2,982 Views)

Your DAQmx Read is set for N channel, 1 sample.  With a DAQ rate of 100 Hz, you will need to have your overall state machine execute in less than 10 msec between reads to not lose samples.  Try setting it for N channels, N samples.  Since you already have 5 msec waits in both the Read and Write states, you are already right there.

 

 

Other tips.

 

Index Array is exandable.  Instead of copying it six times.  Expand the bottom edge of one downwards until it has 7 outputs.  By default, it will give you indices 0 through 6 without even needing to wire up an index to each terminal.

 

Have consistent representations for your wires.  You are reading doubles.  Don't have indicators taht switch that to I8's, and another control that is set for extended precision.  Change all of those to Double Precision and you can eliminate numerous coercion dots.

0 Kudos
Message 6 of 15
(2,970 Views)

I made the above mentioned changes, cleaned up some unecessary/repeated functions and am now faced with lossy data.  You can see in the attached picture, every few seconds or so the data reports zero.  What is happening that is causing this?

Download All
0 Kudos
Message 7 of 15
(2,943 Views)

Try setting your Samples to Read to be 1 instead of unwired which defaults to -1 (all available samples).  If your code is running fast enough, there might be none in the buffer, thus you get zeroes.

 

If you are only asking for 1 (which seems to be that you are only using 1 in your following code.) change it to N channels 1 sample instead of N channels N samples.  Then you can simplify your Index Array function.

0 Kudos
Message 8 of 15
(2,937 Views)

I see no change when I change the read to 1, 10, 100, or 500 samples. 

 

"If you are only asking for 1 (which seems to be that you are only using 1 in your following code.) change it to N channels 1 sample instead of N channels N samples.  Then you can simplify your Index Array function."

 

I changed this to N channels N samples to get rid of a overrun/buffering problem initially (see posts above).  Changing it back will only bring back the overrun problem, unless I have misunderstood your resolution.

0 Kudos
Message 9 of 15
(2,929 Views)

It seemed like your buffer overrun problem must have went away because the symptoms you have now seem like what would happen if you ask for all available samples and nothing is there.

 

Do you get an error message on your DAQmx read now?  Something has to explain where your zeroes are coming from.

0 Kudos
Message 10 of 15
(2,925 Views)