I have a PXI-1045 chassis populated with PXI-6120 series S digitizer modules. I started having problems upon VI launching, receiving daqmx start task error -88709, which states that a device has been removed or a task aborted. A clock device had been swapped from pxi-6653 to 6651 and re-configed in MAX (4.7). I found a blurb on this site about this was a common problem for all versions of DAQmx device drivers prior to 9.2.2, although I had never seen it before teh card swapout. Upgrading to 9.2.2 was the recommended fix which was done without issues. However, the problem persists. Now I also have a new problem when stopping a task, editing it, and re-starting the task. The trigger and clock signals are there... Are these problems related and does anyone have a fix? Thank you!
Solved! Go to Solution.
The error code -88709 appears to reference any task where the hardware has been removed from the system or it is unavailable for another reason.
Error -88709: The specified operation cannot be performed because a task has been aborted or a device has been removed from the system. Handle this situation as required by the application and then, if appropriate, attempt to perform the operation again.
Since you have recently replaced the clock device from the pxi-6653 to a 6651, my initial thought is to step through the code again and check all the references to that module and make sure that they have been updated correctly.
As to whether these errors are related; I believe that they are, and most likely they are referencing the same task that is either aborted or inaccessible.
Here is a KnowledgeBase regarding a similar error to the one you are currently facing:
Thanks Joel.I checked the code and could find no reference to the old clock. Could there be a registry entry still lingering for this device?
I do not believe that a registry setting would be causing this error. A restart of the development system and or chassis may help if there is corrupt memory space. This would not alleviate any registry issue as that is persistent memory, however a repair install would. I do not believe that a repair install is necessary at this point, but it is something that we can consider if other means of resolving this issue fail.
You mentioned that you reconfigured the device in MAX 4.7 and then updated to the latest version of MAX after the error started to occur. Have you tested the devices in MAX since the update? I would be curious to see how the 6651 responds to a self test, or reset. You could also attempt to self test and or restart the entire chassis.
As a last thought, did you use any aliases for the 6653 that may not have been updated since you switched to the 6551?
I hope this helps,
The version of MAX has not been changed...4.7.1. I updated the DAQmx driver set from 8.9 to 9.2.2 as suggested in an article but can't remember where I read this. There are no aliases. One other bit of information is that after the code is restarted several times, the error disappears, as if a shift register or other initialization gets the proper information.
A reseting of each device in the pxi-1045 chassis (pxi-6651 clock and 16 pxi-6120 a/d) not only did not fix the -88709/-89130 problems but also now runs 4 times slower than before once the DAQmx errors are cleared. What's going on here? System seems to degrade after each attempted fix...
I attempted a DAQmx repair with mixed results...the same -89130/-88709 errors are still there on startup but at least the code's natural frequency of execution (4Hz) was restored. Funny, the first launch after repair was errorless, but subsequent launches producd the error. The repair was made off the DAQmx 9.2.2 retrieved off your website, and towards the end of repair re-prompted me to enter the CD or location for the DAQmx verison. it did not accept the 9.2.2 directory, wanted the December 2009 CD version for DAQmx, that I didn't have. Cancelled out of the remainder of repair, but since the code is now operating at the original frequency, that part of the repair must have taken hold. But these missing devices(88709) or routing(89130) errors persist.
I am surprised with the results from the restart and repair attempts, if that were expected I would not have recommended that you perform those actions. I would like to know how the 6651 responds in Measurement and Automation eXplorer (MAX) test pannels, and via MAX self test. Also, using MAX you can create a technical report, by going to FILE >> Create Report... , which may be useful for diagnosing this issue. If you could post a MAX technical report, as well as any addtional information I would appreciate it.
I will continue to look into this error, and let you know if I find any similar cases.
Results from the MAX device test, both VISA test panel and Self-test, indicated no errors. Attached is a MAX technical report.
I'm using NI-Sync to set all clock/trigger properties and connections, and also both DAQmx clock and trigger subVIs to configure the AI tast. Not knowing if this is necessary, the DAQmx clock/trigger calls were deleted to rely solely on NI-Sync. The DAQmx Start Task error disappeared but apparently without the DAQmx trigger subVI the system couldn't read any data; so generally I take it that both are needed?
Just took this bit of data to analyze further the problems I've seen. This system is composed of a process control PC (LV2011) locally networked to 3 clients. The controller has a PXI-1033 with one master time moduel (pxi-6653) and 2 slave timing modules (pxi-6651). Client 1 is clocked/trigged from PFI4+5 from the master. Each client also has a pxi-6651 slave timing module. Sync clock from the master is routed via NI-sync to master PFI pins 1,2,3, which are cabled to the ClkIn of each client slave timing module. The OCXO clock is substituted for the 10MHz master time source. Master ClkOut is cabled to PFI0. The sample clock is routed to both PFI5 and PXI_Trig0. The trigger is routed to master PFI5 and PXI_Trig1 for use by each slave 6651 in the 1033 box. The VI that does this is attached. From the png attachment you can see that exactly at the beginning of the second DAQmx read block (65536 samples/read, so at 250ksps this is .262144 sec), the green plot (client 3) has a clear discontinuity due to either a clocking problem or a DAQmx read pointer problem. The same type of data discrepancy can also occur on client 2 recorded data. When this discontinuity occurs all channels in that client are affected. Interestingly, this behavior has only been observed in clients 2+3 that are clocked off the 6651 slave modules in the 1033. But with the DAQmx routing/device removed errors that originated this thread, DAQmx corruption cannot be ruled out as a cause. Also, when using NI-sync, are settings to DAQmx clock/trig subVIs going to cause conflicts?
Thanks for wading thru all this, Joel.