Error 1000

[kabooom]

Hi all

In a project we use vi Server to Run a top-level VI that calls NI XNET function (LIN) we use an Invoke node with the Run method and set the Wait until done option to False.

To stop this vi we call a Set Control Value  and set the control Stop to true. After this, we check the state of the vi, and abort it if it didn't stop properly after a timeout.

This works properly in labview 2010 SP1, XNET 1.1.1 and with the same code in labview 2014 XNET 14.0 we get the error 1000 when we want to abort the vi (the vi doesn't stop, it stay in the running state). The same code  also works if i set the vi not to be reentrant...

- why this vi doesn't stop properly (maybe an evolution in the XNET driver ??).

- why i can't abort  without an error?

Any idea welcome...

[Sam_Sharp]

Which VI is actually generating the error / what is the content of the error cluster?

A quick google search for the error code shows the following articles:

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

http://digital.ni.com/public.nsf/websearch/790AC75B07D971ED86256C53007BDCE9?OpenDocument

[kabooom]

Thanks for this quick answer

I already read these two answers...

As i said, there are differents weird things:

1) When i check the state of the vi it remains in Running state during 5s....

2) After this i try to abort the vi and this send me the error 1000.

The same code works in Labview 2010 SP1 with XNET 1.1.1. (In the vi i want to stop i use some XNET functions). We didn't change the way how the vi is called or stopped. My guess is that a new version of the xnet driver is blocking something that's why we stay in the running state ... but why can't i abort the vi ...? 

[crossrulz]

If you are getting the error at the Abort method, that tells me that the VI is closing between your check for it to close and when you tell it to abort.  I have heard of weirder race conditions.

Try increasing your timeout before aborting the VI.

[JÞB · Accepted solution]

You cannot abort a sub-vi--- it is part of the caller

Abort Method

Aborts the execution of a top-level VI.

This method returns error 1000 if you call it on a subVI. Otherwise, this method is similar to pressing the Abort Execution button on the toolbar.

If I recall minutia correctly there was a bug fix a while back to fix where that error was not properly reported.  the error was always  supposed to be there but did not report properly.

You may want to update the code to use the Asynchronous Call By reference in a call and collect scheme.  See the examples in 2014

[kabooom]

Hi Jeff!!

Thanks a lot for your answer, as you said i replace the Method Run vi with the Start Asynchronous Call and now i don't have any error when i try to Abort the vi !

Great news, but i still don't understand :

1)You say you remember there was a bug fixe ... do you remember the CAR, in which Labview  version was this bug corrected ?

2) Does it means the method Run Vi doesn't work anymore ? In this case we will have BIG problem...

I think i will contact NI for further informations ....

THANKS !

[Sam_Sharp]

The Run method still works, it's just that using VI Server to launch/communicate/shutdown reentrant VIs is less encouraged (?) than using 'start asynchronous call' and communicating with the VI using queues/events and having it shutdown itself (by telling it to shutdown) rather than 'aborting' the VI.

[JÞB]

---

@kabooom wrote:

Hi Jeff!!

Thanks a lot for your answer, as you said i replace the Method Run vi with the Start Asynchronous Call and now i don't have any error when i try to Abort the vi !

Great news, but i still don't understand :

1)You say you remember there was a bug fixe ... do you remember the CAR, in which Labview  version was this bug corrected ?

2) Does it means the method Run Vi doesn't work anymore ? In this case we will have BIG problem...

I think i will contact NI for further informations ....

THANKS !

---

I vaguely recall the bug discussing the bug several years ago.  Words were said to the effect of "WOW that's a huge mistake to surpress a real error but, WHO WOULD try the Abort method on a sub-vi when the documentation so clearly states that you can't do that!  No one should ever see that error unless they do not understand LabVIEW!  What state would the callers be left in if a sub-vi Aborted!?"  There is rumored to be a test case to prove the fix never gets lost again.