PCI-MIO-16E-4 Error 200329 after running a while

[Bryan]

I am using a PCI-MIO-16E-4 board for a combination signal generator and oscilloscope for a student laboratory exercise.  I use ao0 to generate a waveform of variable frequency (set by front panel controls) and ai6 for acquiring the resulting signal.  For the experiment the two need to be synchronized so the scope acquisition starts simultaneously with the start of an analog generation.  The synchronization is done using ctr0 in generation mode and set to the same frequency as the analog output.  The counter output is routed through rtsi0 to the start trigger on the analog input.

The application seems to run fine until the output frequency is changed "too rapidly" at which time the analog input section will signal error -200329 from the DAXmx Start Task vi.  After receiving this error the computer must be rebooted to recover operation of the board - even the MAX panels will just repeat the same error on analog inputs until a reboot.

If have tried the application on a USB-6221-BNC board (using pfi9 to route the start trigger signal) and have been unable to cause the same error to occur.

This is on a computer running Window 7 Enterprise sp1 with LabVIEW 2012 sp1 (32-bit) with the f5 patch installed.  DAQmx 9.6.2 was installed for the original tests for both boards.  Installing DAQmx 9.8.0f0 didn't change the behavior.  The PCI-MIO-16E-4 passed the DAQ Diagnostic Utility 2.1 tests.

I have tried using both rtsi6 and rtsi0 as the trigger routing signal with no change in behavior.

I have attached a stripped down version of the application that still exhibits the problem.  There are 7 required files so they are in a single .zip file.  With the knob to set the frequency it usually just takes a couple of "twists" of the knob to cause the analog input to throw the error.  The output from the DAQ Diagnostic Utility is also attached.

Thanks for any hints on what I may have done wrong in this application.

[eaguero]

Hi Bryan,

What do you mean with "too rapidly" frequency?

There are other forum topics about this error: http://forums.ni.com/t5/Multifunction-DAQ/error-200329/m-p/500416

This seems to be an issue with the sample clock when doing hardware timed analog input tasks. Can you please try to do an Analog Input task on the Measurement and Automation Explorer's (MAX) Test Panels using Continuous Samples to see if you get this error? If you do, please try the following: 

I recommend you to download and run the DAQ Diagnostic Utility to see if there is an error with the master timebase 
http://joule.ni.com/nidu/cds/view/p/id/2244/lang/en 

Regards

[Bryan]

This error is different from the one frequently reported because I am not using hardware timing.  I am using the internal counter to generate a start trigger signal but the subsequent acquisition uses the internal clock.  The application will run for hours with no problems UNTIL the frequency of the analog output (and internal counter) is changed using the front panel control.  "Too rapidly" can be demonstrated by taking the dial control on the front panel and running it from 1 to 10 and back to 1 a couple of times with each rotation taking a couple of seconds.  In most cases it will only take two rotations before the analog input indicates the error.  I have also had the application run with only a numeric control to change the frequency so the students would either enter a number directly or use the up/down controls to change the value.  Even then it would eventually hang.

It is entirely possible that it is actually the trigger signal that is getting lost but the error comes almost immediately - the trigger timeout would have to be less than a second.  All the timeouts are left at the default value when the device is configured.

After LabVIEW reports the error, running MAX and trying an analog acquitision of any kind just repeats the same error with never acquiring a single sample.

[Bryan]

Incidentally, I already ran the Diagnostic utility and the board passed all the diagnostics (the report is attached to the original post).  Interestingly, I have tried this application on 3 different boards in 3 different computers.  They all exhibit the same behavior.  Two of those boards passed the diagnostics with no errors.  The third never completes the first step of the diagnostics but the board seems to work properly for all our other applications.

[eaguero]

I am sorry, I did not read that you already tested it with the Diagnostic Utility.

Just to be sure, is this the way you are doing it?

http://digital.ni.com/public.nsf/allkb/ADFC4DD8C9690232862575B70079FBD4

[eaguero]

Would helpful for you to use the Analog Output task as a trigger?

[Bryan]

I didn't see a way to use the analog output to trigger the analog input because we are using a continuous, recirculating output and I couldn't see any signal that would indicate that it is starting over in the output buffer.  I could only find a signal that it was starting the first time.  But I may have overlooked some fine detail of the timing.

I didn't use an analog trigger, which this board can use, for two reasons. First, the amplitude will not necessarily be sufficiently large because they are looking at the voltage from the different components of an LRC circuit, and second, I also use the application on the USB-6221 which does not support analog triggering.

However, I will have to see if the problem occurs with analog triggering instead of synchronizing with the counter on the PCI-MIO-16E-4.  That may be a way around the problem in the short term if it will work.  Thanks for the comments that point toward a possible solution.

[Bryan · Accepted solution]

The solution to the error:

First attempt, the application had two parallel event structures that allowed the frequency to be changed while there was also an acquisition occurring.  Changed to have a single event structure so that changes to frequency could only occur between acquisitions (potential conflict in board access?).  This made no difference to the error.  It would still get error -200329 after the frequency was changed a few times.

Discovered that just resetting the board would clear the error.  Considered trapping the error and resetting the board anytime it occured.  Prefer something that will prevent the error from happening at all.

Final solution was to clear the data acquisition task after each sweep acquisition and reinitialize it.  It was only necessary to clear the acquisition task and not the output or timer tasks.  After several hours of changing frequency, amplitude, and phase no error had occurred.  I believe that this has cured the problem.

I now have two different copies of the application.  One is for use with the PCI-MIO-16E-4 (the new one that clears the acqusition task after each sweep) and one for use with the USB-6221 that still uses the two parallel event structures, never clears the acqusition task, and also never shows the error when used with anything but the PCI-MIO-16E-4.