Error -88710 when abort DAQmx task

[pgaastra]

Hi,

I am getting Error -88710

Possible reason(s):

The specified operation cannot be performed because a task is in the process of being aborted or a device is in the process of being removed from the system. Wait until the abort operation is complete and attempt to perform the operation again.

Task Name: _unnamedTask<4>

I am trying to stop a DAQmx task using the DAQmx Control Task.vi by wiring in abort.  The task wire forks after the start task VI one leg goes to the rest of the code and the other leg goes to code with the abort in it.  I got that from some example on the web.

I have included the VI. 

I have seen reference to saying I should "catch and clear the error".  Sounds a bit suspect to me.

I am using LabVIEW 2012 with a DAQPad 6-15.

Thanks for any help.

P.S.  I have real trouble trying to find a list of LabVIEW errors anywhere.

[Freelance_LV]

Hi

could you post your code in lv2010 or lower please?

thank you

now to the error you see...... i was not able to look at your code but this is my guess:

1. to stop a task, we usually use stop task and clear task.. not abort.

2. from what you described.. task wire forking in two parts... you must be getting the error from the first part of the fork... where the rest of the code is..

what you are doing is... trying to abort the task while the same task is being used elsewhere.. both are being done in parallel... take your task wire through the rest of code, finish your code and then take it to the stop task function.

check the example vi "Cont Acq&Graph Voltage-Int Clk.vi" in the NI example finder for basic daqmx functions and their wiring.

[pgaastra]

Thanks Freelance LV

I agree that the preferred way is to stop the task but I have to acquire a fixed number of points after a trigger which may happen seconds later.  So I have the task stiiting there waiting for the trigger with no timeout.  I thought the only way to stop it is with the fork.

I have included the VI again saved for LV 2010

[Freelance_LV]

Hi

Where is this error coming? I mean, at which function does this error occur?

[JÞB]

---

@pgaastra wrote:

Thanks Freelance LV

I agree that the preferred way is to stop the task but I have to acquire a fixed number of points after a trigger which may happen seconds later.  So I have the task stiiting there waiting for the trigger with no timeout.  I thought the only way to stop it is with the fork.

I have included the VI again saved for LV 2010

---

That is probably the oddest attempt at re-desiging a state machine I have ever seen.  DO look in the shipping examples (I see you did find the poor example "Acq&Graph Voltage-Int Clk-Dig.vi)   A Fast search of the forums for "State Machine" or Queued Message Handler will likely give you some ideas about how to better implement your desired funcionality.

For myself I would also consider breaking up this code into specific functions "Init, Close, Configure, Start, Check if done?, Read, Abort" and use an Action Engine (Resource Module) to encapsulate those functions.

[Kevin_Price]

This isn't fully functional, just a quick demo of a way to wait indefinitely for a trigger while remaining responsive to a stop notification.  The key is that instead of a single infinite wait you set yourself up to do an infinite # of short waits until the trigger comes in.

-Kevin P

[JÞB]

As an example I whipped out this Resource Module directly from the example (With an abort method)

UNFORTUNATELY I also ran into a error saving the VI (something went insane I Guess)  So for any NI AE's out there You may want to peek at this attachment and CC to see what went wrong with LabVIEW here.

Report sent

text below

####
#Date: Fri, Aug 31, 2012 10:34:15 AM
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: LabVIEW
#Version: 11.0 32-bit
#AppKind: FDS
#AppModDate: 06/22/2011 16:12 GMT
#LabVIEW Base Address: 0x00400000

Possible path leak, unable to purge elements of base #0

[alcava.cr]

Hi there, I examined the "Aweta Only.vi" and the example Kevin posted, the errors I got came always from the notifiers, I could not load the last code Jeff posted. I got error 1100: No object of that name was found. No reference could be return. I fix this by setting to true the terminal "create if not found?" at the obtain notifier.

Now, I agree with Jeff that there is a better way to do things, take a look at the example called "Acq&Graph Voltage-Int Clk-Dig Ref.vi" you can control pre & post trigger samples and I checked that this is a feature that your hardware can support.

I hope this helps

[Kevin_Price]

I'm not so sure the "Acq&Graph..." example really addresses the problem of a triggered task that may need to wait a *very* long time for a trigger, but which may also need to be interrupted/stopped/aborted based on other stuff in the program.  Won't the DAQmx Read call just block and then timeout if there's no trigger?  Or won't it block indefinitely if the timeout is set to -1?  Or does the o.p.'s DAQPad device behave differently than I expect for that code?

As to the snippet I posted, I see I didn't really describe *how* it isn't fully functional.  I meant for that snippet to replace a middle chunk from the "Aweta only.vi".  The "Obtain Notifier" in particular is configured NOT to create a new notifier, but to return a reference to a pre-existing one, similar to the original code.  Attempting to run it as is would definitely produce an error.  Similarly, I left out the other DAQmx stuff to focus on the parts between start and stop.  I would normally query the error status just *before* the right-hand shift register too, but didn't want to make the diagram that much wider for only that purpose.

Having said all that, I'd also highly recommend Jeff's advice to package the DAQmx task into an Action Engine.

-Kevin P

[JÞB]

---

@Kevin Price wrote:

I'm not so sure the "Acq&Graph..." example really addresses the problem of a triggered task that may need to wait a *very* long time for a trigger, but which may also need to be interrupted/stopped/aborted based on other stuff in the program.  Won't the DAQmx Read call just block and then timeout if there's no trigger?  Or won't it block indefinitely if the timeout is set to -1?  Or does the o.p.'s DAQPad device behave differently than I expect for that code?

As to the snippet I posted, I see I didn't really describe *how* it isn't fully functional.  I meant for that snippet to replace a middle chunk from the "Aweta only.vi".  The "Obtain Notifier" in particular is configured NOT to create a new notifier, but to return a reference to a pre-existing one, similar to the original code.  Attempting to run it as is would definitely produce an error.  Similarly, I left out the other DAQmx stuff to focus on the parts between start and stop.  I would normally query the error status just *before* the right-hand shift register too, but didn't want to make the diagram that much wider for only that purpose.

Having said all that, I'd also highly recommend Jeff's advice to package the DAQmx task into an Action Engine.

-Kevin P

---

Those "Resource Modules"  or, "Action engines" that encapsulate a specific IO, Do make for code that is very vicely modular and maintainable. 

Thanks KP!

On the other hand-  WTH happened when I tried to save that VI that caused a heep problem?