topic Re: daqmx start task error -88709 in LabVIEW

daqmx start task error -88709

lebecker — Wed, 01 Aug 2012 23:45:49 GMT

Hi All,

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!

Re: daqmx start task error -88709

Joel-P — Tue, 04 Nov 2025 18:33:56 GMT

Hello Lebecker,

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:

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

Thanks,

Joel

Re: daqmx start task error -88709

lebecker — Fri, 03 Aug 2012 16:33:55 GMT

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?

Re: daqmx start task error -88709

Joel-P — Fri, 03 Aug 2012 18:42:58 GMT

Hello Lebecker,

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,

Joel

Re: daqmx start task error -88709

lebecker — Sat, 04 Aug 2012 13:23:41 GMT

Hi Joel,

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.

Re: daqmx start task error -88709

lebecker — Sat, 04 Aug 2012 15:55:26 GMT

Hi Joel,

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...

Thanks Joel,

Re: daqmx start task error -88709

lebecker — Sat, 04 Aug 2012 18:54:37 GMT

OK Joel,

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.

Re: daqmx start task error -88709

Joel-P — Tue, 07 Aug 2012 03:06:05 GMT

Hello Lebecker,

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.

Thanks,

Joel

Re: daqmx start task error -88709

lebecker — Tue, 07 Aug 2012 11:13:16 GMT

Joel,

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?

Thanks Joel,

Re: daqmx start task error -88709

lebecker — Tue, 07 Aug 2012 20:04:31 GMT

Joel,

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.

Re: daqmx start task error -88709

lebecker — Tue, 07 Aug 2012 22:27:12 GMT

Joel,

Just one more tidbit...after analyzing another group of acquisitions it is clear that:

1. Consistent data sample dropouts (new samples either not taken or placed in read buffer) for 150 microsec, after which samples resumed. All channels in the chassis are affected.

2. All 3 clients scan exhibit this behavior, usually just one/acq but sometines 2.

3. On one occasion intra-chassis channels were in phase while inter-chassis channels were out of phase, but none exhibited dropouts.

4. About 50% of acquisitions were perfectly good.

5. I'm thinking either sync or sample clock breakdown. Or DAQmx issues. Or maybe the NI-sync connections. Or mixing in DAQmx timing subVIs with NI-sync. Or...

Re: daqmx start task error -88709

Joel-P — Tue, 04 Nov 2025 18:35:25 GMT

Hello Lebecker,

Thanks for the additional detail on this issue. Based on these concerns, I have several ideas for troubleshooting or resolving this issue.

Here is a knowledgeBase (KB) article with troubleshooting steps for the 89130 DAQmx error. Along with this KnowledgeBase, I would recommend updating DAQmx and NI-Sync to the latest possible versions (9.6 and 3.3.5 respectively) as well as following the troubleshooting steps in the KB.

DAQmx Error Code -89130: Device is not Available for Routing:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8k8SAC&l=en-US

DAQmx 9.6:

https://www.ni.com/en/support/downloads/drivers/download.ni-daq-mx.html#288357

NI-Sync 3.3:

http://joule.ni.com/nidu/cds/view/p/id/2496/lang/en

Also, there is a KnowledgeBase regarding the CLKIN port of the 6553 to a PXI chassis that may be useful.

Routing CLKIN of PXI-6653 to PXI_CLK10_IN of PXI Chassis:

http://digital.ni.com/public.nsf/allkb/2415F652232FDE01862574F3004E2C39?OpenDocument

There is an example VI that is very similar to what you are attempted to create, I would like to try it and see how the acquisition responds. Please run this VI, and in particular look at steps 16-20 on the block diagram where the terminals and clocks are disconnected. You may have this example VI already, but I have also attached it for easy use.

Share PXI_CLK10 and Synchronous Trigger Between Chassis

Finally I would like to clarify the current setup with the pxi chassis, could you describe the hierarchy of pxi chassis with the cards installed. At first I thought that the host computer was attached to the main controller chassis (a 1045) that connected to three client pxi's that are 1033 chassis, but your previous post made me unsure.

As a last note, I will be bringing in another Applications Engineer to help work on this issue with us in order to bring this issue to resolution quickly.

Thanks,

Joel

Re: daqmx start task error -88709

lebecker — Thu, 09 Aug 2012 13:56:44 GMT

Hi Joel,

I've attached a png file of the basic layout, that will hopefully assist you guys in visualizing the system.

I had read the KB article about the 89130 error fix that lead me to the device resets that you later had not recommended. I thought resets were for transitioning back to DAQmx from using Traditional NI-DAQ driver sets?

I'm not sure the PXI-1033 box we have has the backplane switch mentioned in the routing CLKIN article...we are using the OCXO oscillator on the 6653 for CLKIN10.

The latest DAQmx version (I think) that the clients (WinXP, LV8.5, MAX 4.7.1) can use is the current installation (9.2.2). I had tried to install the same version (9.4) that the controller (Win7 64-bit, LV 2011, MAX 5.0.0) uses but it would not install on the XP clients. There was a table on your website that listed all the compatibilites between DAQmx versions and Windows OSs but i can't find it now.

I'm incorporating the terminal disconnect/session closing shown in your example. Do you think there is some collision between unclosed sessions/routings and current requests when the VI is launched?

Added assistance is always a help to accelerate solutions, so a second set of eyes is welcomed...I've really got to get these boxes humming!

Thanks guys,

Re: daqmx start task error -88709

lebecker — Thu, 09 Aug 2012 14:19:42 GMT

PS...

Forgot to mention that we have an additional PXI-6653 that could be substituted for the 2 6651s?

Re: daqmx start task error -88709

lebecker — Thu, 09 Aug 2012 23:08:06 GMT

Hi Joel,

A quick question about how to close old session (niSync) handles. I thought LV (running 8.5 on clients) closed old handles when LV was closed. Why do I see the instrument handle name with a (I guess) session number in parenthesis? I take this to mean the previous session did not close properly. Can't find any info on this in the discussion forum or KB. Thanks Joel

Re: daqmx start task error -88709

TylerK — Tue, 14 Aug 2012 17:57:29 GMT

Hi Lebecker,

If you see an instrument handle name staying around after a VI has been run, it means that niSync Close.vi was not called for that session. The niSync Initialize VI creates an NI-Sync session and then calls IVI New Session.vi which associates the resource name with the NI-Sync session and returns an IVI session handle. The niSync Close VI destroys the NI-Sync session and deletes the IVI session. When a VI is aborted or stops with an active NI-Sync session, the NI-Sync session gets cleaned up, but the IVI session will remain.

Just as a side note: When you create multiple sessions to an NI-Sync device, the number in parenthesis of instrument handle name is used to make each name unique and does not necessarily reflect the session number.

Regards,

-Tyler

Re: daqmx start task error -88709

lebecker — Tue, 14 Aug 2012 18:53:11 GMT

Thanks Tyler, that was a very good explaination.

Re: daqmx start task error -88709

TylerK — Tue, 14 Aug 2012 22:52:12 GMT

Hi Lebecker,

I took a look at the G550_ClkTrig_config4.vi you posted. The following are a few suggestions to help out with the synchronization:

1. When you route PFI0 to PFI[1..3], you should remove the synchronization clock input to the niSync Connect Trigger Terminals VI. By default, NI-Sync creates asynchronous routes which are preferred for distributing clocks. Synchronous routes were designed to align triggers to a rising or falling edge of a clock and only update the output terminal on the specified clock edge. When using the DDS as the synchronization clock source for the terminals, the 10Mhz clock wired to PFI0 will be aliased by the DDS frequency on the output terminals PFI[1..3].

2. As for the start trigger, I would suggest that you make the paths to the DAQ devices symmetric. Each asynchronous route through a 665x device generally delays a signal in the order of 10s of nanoseconds. To better align the trigger to the client chassis, keep the software trigger route to the backplane, but replace the software trigger route to PFI5 on the 6653 with a route from the backplane to PFI5. For now, I would make the routes from PXI_Trig1 to the PFIs asynchronous.

3. I am not sure how well you need the chassis synchronized to each other. Though to achieve nanosecond level of synchronization, you will want to match path delays for clocks and triggers. For example, by routing the PXI-6653s OCXO to PXI_Clk10_In and then exporting PXI_Clk10 to the client chassis, the chassis will have a phased locked 10Mhz clock but not phase aligned. To ensure that your clocks are both phase locked and phased aligned, you can make the following changes:

a. On the PXI-6653, route OCXO to ClkOut
b. Wire ClkOut to a 4-way splitter
c. Wire the outputs of the splitter to ClkIn of each system timing module in a system timing slot (including the PXI-6653). Make sure each wire is matched trace length.
d. Then route ClkIn to PXI_Clk10_In

Similar techniques can be applied to the trigger and sample clock routes that don’t necessarily require an external splitter.

I hope this helps,

-Tyler

Re: daqmx start task error -88709

lebecker — Wed, 15 Aug 2012 14:51:13 GMT

Hi Tyler,

Your suggestions made good sense so I changed the code and cabling to what (I think) you were recommending. Although not specifically stated, I also disconnected all synch clock sources for all trigger connections, both server and client connections. Attached are the VI, diagram of the system as it now exists, and read block error. I got the following results:

1. The master synch clock (OCXO) is measured at 20 MHz (was 10MHz) at PFI0 on 6653).

2. Client 1 measured sample clock was 120 khz (should be 250 kHz according to DDS settings).

3. Client 2 measured sample clock was 250 khz as it should be.

4. I still get the same data discontinuity after read block #1 in recorded data, but it maybe app related instead of clocking error...

Hopefully I have made some block-headed error that you will immediately spot...

Re: daqmx start task error -88709

lebecker — Wed, 15 Aug 2012 16:11:42 GMT

Tyler,

I noticed in the previous VI version I had left the synch clock inputs wired on the 2 1033 slave 6651s...these have been disconnected and also on the client case were the trigger was wired. The results are the same...