cDAQ 9172 generates error 200361 randomly - another computer does not

[Nharknett1]

With my cDAQ 9172, I am using a VERY low sample rate ~1 sample / second and will randomly get error 200361.  Sometimes the program will run for 4 days without an error, but occasionally it happens after only a few minutes of running.  On another computer, this error does not seem to occur.

Any ideas as to what is going on?  I am using DAQmx and am recording at well below the maximum rate.

[MarkGrot]

I don't know enough about your application to say exactly what is going on, but I have a few ideas.

Let me know if you need to know how to get any answers to the questions I'm asking below.  I don't know what API you are using.

What modules are you using in your cDAQ-9172 chassis?  How many channels on each? 

Are you configuring your sample rate to 1Hz or are you using an external clock?  If you are using an internal sample clock (by setting the clock rate but not source) then it is possible that you are acquiring faster than you think which means you are generating more data than expected.  After verify, commit, or start read back the sample rate.  This will be your coerced rate.  See if it matches your desired rate (or is close)

If you are manually configuring your buffer size, what are you setting it to?  If you are not, query the buffer size after verify/commit/start.  What is it set to?  Configuring a larger input buffer could help (but not solve) your problem.

Finally, are you reading a set number of points back or all available samples?  How often are you reading?  It could be that your code assumes a set rate of data generation that is slower than actual or something is delaying your read longer than expected.

Message Edited by MarkGrot on 09-11-2008 02:50 PM

[Nharknett1]

MarkGrot,

  I definitely appreciate your help.  Sorry for not getting back sooner I was out of the office.  Please see my responses below: 

---

MarkGrot wrote:

I don't know enough about your application to say exactly what is going on, but I have a few ideas.

Let me know if you need to know how to get any answers to the questions I'm asking below.  I don't know what API you are using.

What modules are you using in your cDAQ-9172 chassis?  How many channels on each? 

  I am using the following modules:

    9211 (2 channels used)    9265  (2 Channels Used)    9481 (4 channels used)  9401 (1 channel used)     

    9205 (5 channels used)

Are you configuring your sample rate to 1Hz or are you using an external clock?  If you are using an internal sample clock (by setting the clock rate but not source) then it is possible that you are acquiring faster than you think which means you are generating more data than expected.  After verify, commit, or start read back the sample rate.  This will be your coerced rate.  See if it matches your desired rate (or is close)

    My appologies, another engineer had actually configured the sample rate to 1kHz, not 1 Hz.  I have confirmed that it is configured to 1kHz using "continuous" mode with a sample length (what i understand to be equivalent to a buffer size) of 100 samples. 

   How can I read back the sample rate?  Is this in MAX or something I can put in my code?

If you are manually configuring your buffer size, what are you setting it to?  If you are not, query the buffer size after verify/commit/start.  What is it set to?  Configuring a larger input buffer could help (but not solve) your problem.

  I have the "number of samples" configured to 100 samples in continuous mode in MAX.  Is this the buffer size you are referring to?

Finally, are you reading a set number of points back or all available samples?  How often are you reading?  It could be that your code assumes a set rate of data generation that is slower than actual or something is delaying your read longer than expected.

  I am reading all available samples back.  I read at the full speed of a loop execution with no delay or anything in the loop.  I also perform a point by point mean function on it with a sample size of 5. 

Message Edited by MarkGrot on 09-11-2008 02:50 PM

---

[dansch]

Hi Nharknett1,

Based on your description of the problem, this seems very similar to the issue referred to in the online KnowledgeBase article 3MFHA100 titled "Error -200361 with USB-9201,USB-9221, NI 9233, USB-625x or USB-621x". Though the cDAQ-9172 isn't explicitly listed in this KB article, it is a USB device and the symptoms of your problem seem the same. Please let me know if you are using the same version of that file or if this solution appears to resolve the issue or not. Hope this helps,

[MarkGrot]

As Daniel said, make sure that that you are using the latest service pack.  2k SP4, XP SP2, and Vista SP1 fixed a number of USB issues so you should have those or newer.

Another possible issue is that you are running at full speed instead of high speed.  Page 17 of the cDAQ-9172 manual describes this.  The Ready LED will be amber when the chassis is in high speed mode.  If the ready light is green, try connecting your chassis to a USB 2.0 port.  Many computers have a mix of 1.1 and 2.0 ports.

Do you have any CPU intensive applications running?  Is the chassis connected to a hub?  Are you using other USB devices as well?

Those are the easy fixes.  You really shouldn't be overflowing at that rate with those channels.  If none of that works we can try other solutions.

[Nharknett1]

Prior to posting, I read that support notice and made sure everything is up to date.  My XP install has service pack 2 and all the additional latest updates.

The ready light is amber and I am running in high speed mode.

No CPU intensive application are running.  NOTHING is running except Labview and the NVidia display manager that comes with my video driver.  I spent a good bit of time disabling windows services and auto-start programs to get it bare-bones.

What I have done to get things working for the meantime, is I changed the sample rate to 100Hz and changed the #samples to 1000.  This seems to have solved the problem, although it may just delay when I see it. 

Thank you both for your help.  If you have any other ideas, I'd be glad to hear them, but your help has already been VERY informative - especially yours, MarkGrot.

Regards,

  Nick