Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -88709

Solved!
Go to solution

For background information, I'd like to point you to a post I found in which a user describes my situation almost exactly:

http://forums.ni.com/ni/board/message?board.id=250&message.id=22058&query.id=737852#M22058

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.

Thanks,
jm

0 Kudos
Message 1 of 6
(8,423 Views)

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.

0 Kudos
Message 2 of 6
(8,420 Views)
Image 11: start Mirror Acquisition Task.  The local variable in an above loop refers to this indicator.
0 Kudos
Message 3 of 6
(8,419 Views)
I would imagine that this is very much a race condition, and one that is not present possible with probe watching or highlight execution because of the different run speeds that presents.  It would entirely make sense with the error code you are seeing if the local variable were read from and passed onto the DAQmx Read VI before the local variable had even been written to in the other loop.
Doug Farrell
Solutions Marketing - Automotive
National Instruments

National Instruments Automotive Solutions
0 Kudos
Message 4 of 6
(8,347 Views)

Hi Doug,

 

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

 

DAQmx:

Start Mirror control button -> Configure Mirror Output (DAQmx AO) ->Configure Mirror Acquisition (DAQmx AI)->Start Mirror Output-> Start MirrorAcquisition.

 

 

Scope:

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.

0 Kudos
Message 5 of 6
(8,332 Views)
Solution
Accepted by jamoore84

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!

 

To summarize:

 

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.

 

jm

Message 6 of 6
(8,289 Views)