09-08-2009 02:45 PM
For background information, I'd like to point you to a post I found in which a user describes my situation almost exactly:
I have a 6251 DAQ which I use to control a 2 axis scanning mirror (ao0:1), and read back the mirror voltages (ai0:1). Recent changes to parts of theDAQ IO configuration code have produced a-88709 error, which states that "The specified operation cannot be performed because a task has been aborted or a device has been removed from the system." This occurs directly after DAQmx Read.vi I have since attempted to revert the code to versions prior to this error, but this issue remains.
The smoking gun may lie in the configuration --DAQ channels and tasks are created, configured, and initialized in one "Main Loop", while the DAQmx Read.VI is evoked in a separate while-loop. A Local Variable is used to pass the appropriate task between these loops.
I know, I know, Local Variables are BAD and I'm getting a taste of that now, but I'm stumped for the following reasons:
1. The error only occurs after the DAQmx Read.vi
2. I've followed the task in question with probes and it exists throughout the signal chain (through the local variable), right up to the DAQmx Read.vi. I've surmised that the task is not aborted, if only because i am able to follow and identify it's name up through the problem spot.
3. Calling the DAQmx Read.vi from the Main Loop does not cause this -88709 error.
A sane man would infer that his problems stem from the local variable and perhaps some unforseen race condition. However, I am a well rounded individual and in addition to striving for sanity, I'd like to know how this might happen, especially when the local-variable setup worked "perfectly well" up until now.
Nothing should be able to abort this task unless the user ends it. I'm sure this holds little water once you get behind the scenes, so please let me know what might have happened that could cause a seemingly healthy task to die. The other option of "device removed/disabled" seems very unlikely, which is to say it's probably a real concern. Any thoughts on this as well?
In addition to this, I seem to have lost my mirror control. Commands to move mirrors no longer work, which may or may not be related to this issue.
Unfortunately, the 2006 thread was never wrapped up, so I'm not sure what the culprit is. I will upload code screenshots of the DAQ config sequence, which will hopefully aid a more practiced eye with spotting some problems. P
lease respond with any questions or critques.
Solved! Go to Solution.
09-08-2009 02:54 PM
Image 2: Initialization of Mirror Task (for analog voltage generation). The three subVIs create the waveform, prime the mirror (read first index of X and Y waveform and position mirror), then create the "mirror task".
Image 9: Configure Mirror Acquisition. This creates the task which reads backvoltages.
image 10: Start Mirror Task
The update rate of these channels is determined by an external clock.
09-08-2009 02:56 PM
09-10-2009 11:42 AM
09-10-2009 12:29 PM
After some debugging with the help of an NI rep, it appears that the DAQmx "Mirror Acquisition Task" is aborted when I configure the PXI-5152 digitizer directly after it. The GUI has two "start/stop" button sets - one for the DAQmx configuration and one for the Scope configuration
Start Mirror control button -> Configure Mirror Output (DAQmx AO) ->Configure Mirror Acquisition (DAQmx AI)->Start Mirror Output-> Start MirrorAcquisition.
Start Acquisition button->Configure Acquisition -> Start Acquisition.
Clicking the stop button for either of these serves to clear the current tasks.
This is a little long-winded, but we narrowed the problem down to the "Configure Acquition" step of the Scope code. The DAQmx tasks (input and output) are clocked by the Scope's "EndOfRecordEvent" trigger. Our reasoning is that configuring the DAQmx tasks to use this scope trigger, and then configuring the scope somehow causes these DAQmx tasks to be dropped. We re-arranged the order in which the configurations occur and fixes my previous problem.
we've contacted NI support and they are looking into it. I'll check back and let you know if they reproduce it.
Some supporting evidence: I recently updated the NI-Scope Drivers (and others), to fix a problem I was having with the scope.
Fly in Ointment: This was some time ago and this error just recently cropped up.
I will check back and let people know how this works out.
09-17-2009 08:30 AM
Just checking back in to clear up some of the previous speculation on the source and solution to this error:
Troubleshooting had narrowed the issue down to the DAQmx task being invalidated during the scope config subVI, specifically during "Initialize NI Scope". I had wired a TRUE value to the "Reset Device" property, which caused the scope to temporarily "not exist" in the system.
This caused problems because my DAQmx tasks set their external clock to the Scope's "EndOfRecordEvent" signal. when the scope "disappeared" briefly, so did the signal source, and the DAQ tasks were aborted. This is why configuring the scope before the DAQmx tasks cleared the problem - nothing was dependent on the scopes state when it was reset.
Another solution is to export this signal to another location using the "niScope Export Signal.vi". This lets you route a scope signal to route to a separate output terminal. I chose to send the "EndOfRecordEvent" to "PXI_Trig0". Now, rather than setting the DAQmx tasks to clock off of the scope, you point them to the PXI_Trig0 line, which will always be there, even if the scope is reset!
The -88709 error was generated from resetting the scope when a DAQmx task was using it as an external clock source. Possible solutions to this problem are:
1. Don't reset the scope when you are configuring/initializing it.
2. Configure/initialize the scope before you create other tasks which will require some property or signal from the scope for normal operation.
3. Re-route any scope signals which other tasks or hardware relies on using "niScope Export signals", and point the dependent tasks to this new location.
Number 3 is the best one. This keeps the dependencies from aborting if ever the signal source is temporarily interrupted.
I hope this saves some people time and trouble.