System exec with a timeout

[Ton Plomp]

I try to use the standard LabVIEW systemexec.vi with a timeout and wrote a little wrapper around the VI:

However this is not functioning as expected, the AbortVI returns an error 1000:

The VI is not in a state compatible with this operation. This error can occur for several reasons. This error can occur if you attempt to edit a VI that is running or reserved for running. This error also can occur if you attempt to open a reference to a VI that is running or reserved for running. A VI is reserved for running when you open a reference to the VI by wiring a type specifier VI Refnum to the Open VI Reference function, or when you have a Static VI Reference linked to the VI within a running VI. This error also can occur if you try to run a VI using the run method while the target VI is running or reserved for running. To correct this error, ensure the target VI is idle or reentrant. If it is reentrant, use the Open VI Reference function with the options input set to 0x08 to prepare the VI for reentrant run or use the Open VI Reference function with the type specifier VI Refnum wired to a strictly typed VI reference. This error also can occur if you attempt to obtain a VI's image while the VI is being modified programmatically. Wait until the VI is not being modified to get the image of a panel or diagram.

The only thing I found was a thread of last year, that concluded in a taskkill.

EDIT: At the dark side there is a discussion. This has a solution where the command is run asynchronously and the output is written to a temporary file that is read the function times out, not something I am looking forward to do.

Anyone ever looked at this?

Ton

[asbo]

Unfortunately, I don't have anything useful to add - just that every time I've need to have a timeout on a SysExec, I've also used the taskkill solution. It's not pretty (and I don't remember if you even get any stdout back) but it works.

[SuperS_5]

Running this in LV2010 worked without issue. (used "ping www.google.com" for cmd line)

Edited December 17, 2010 by SuperS_5

[Ton Plomp]

Running this in LV2010 worked without issue. (used "ping www.google.com" for cmd line)

Yes that runs without an error since it doesn't time out (it returns before the timeout is exceeded), you could alter the cmd string to "ping www.google.com -t" that will ping until the cmd is terminated.

Ton

[ShaunR]

Do you have to use Exec? Is multi-platform a must?

[Ton Plomp]

Do you have to use Exec? Is multi-platform a must?

Yes, almost.

[ShaunR]

Yes, almost.

Shame. The problem is you don't have access to the command window reference so you can't even send it a Ctr-C, exit or terminate it directly. You could do it if you invoked a command prompt using api calls though.. And you could probably do it with a batch file or script. But none of that is portable.

[asbo]

Has there ever been talk of a proper process I/O library for LabVIEW? 'Cause that'd totally be awesome.

[ShaunR]

Has there ever been talk of a proper process I/O library for LabVIEW? 'Cause that'd totally be awesome.

Post it here when you've written it an I'll give you a rep point

[asbo]

Post it here when you've written it an I'll give you a rep point

Oh, boy, a WHOLE rep point? It'd be tough to make cross platform.

[SuperS_5]

Yes that runs without an error since it doesn't time out (it returns before the timeout is exceeded)

Ton

dohh..... Should have known that. I guess it is time for more coffee.

[Ton Plomp]

Running my SystemExecTimeOut.vi makes my LabVIEW installation very very buggy, it is very prone to crashing (almost every run), so I guess I let the function go.

Ton

[Rolf Kalbermatter]

I try to use the standard LabVIEW systemexec.vi with a timeout and wrote a little wrapper around the VI:

The only thing I found was a thread of last year, that concluded in a taskkill.

EDIT: At the dark side there is a discussion. This has a solution where the command is run asynchronously and the output is written to a temporary file that is read the function times out, not something I am looking forward to do.

Anyone ever looked at this?

Ton

Well the OpenG pipe library has a System Exec equivalent that also returns besides the pipes for the stdIO and optionally stdErr the resulting task ID. And then another function which can be used to kill that task. Works like a charm for me for starting up command line tools that have no built in remote control to quit them.

The OpenG Pipe library has not been released as a package but can be found here as a build OGP package.

[asbo]

The OpenG Pipe library has not been released as a package but can be found here as a build OGP package.

Is that the post you intended? The attachment only refers to some clipboard and BMP-related libraries ...

[KFadgen]

We've been playing with dotNet Processes of late to interact with command line applications, unfortunately it's windows specific. I've attached a very crude proof of principal we used to see if it would work for us. We're in the process of trying to make a generic OOP class around this which we can apply to a couple different command line apps. To date, we've only used the output stream reader. There is one for input as well as error that should work without a problem. We have played around with the pipes library as well but figured since we're platform specific already why not try the dotNet routines first.

-Keith

[asbo]

We have played around with the pipes library as well but figured since we're platform specific already why not try the dotNet routines first.

I go back and forth as to whether a Windows API or dotNet implementation would be more finicky .. dotNet certainly has the advantage of already being written for you

[mje]

However this is not functioning as expected, the AbortVI returns an error 1000:

I've seen this. It's related to some static reference voodoo, and when you try to allocate new copies of the reentrant VI it doesn't quite work. Banged my head for a while on that one when I was creating my messaging library.

You should be able to do what you need using generic (non-strict) references. Unfortunately this means interacting with the front panel and doing value set/get methods for each item, dealing with variants, etc. Slow, but I doubt you're going to be doing this in a tight loop or anything. REALLY crude proof based off your original code:

You then need to retrieve the control values...Messy I know, but as far as I can tell it's the *only* way to go if you want platform independency.

Keith's proof is really the best way to do it (once the polling is removed) if you can stick with Windows...

[Rolf Kalbermatter]

Is that the post you intended? The attachment only refers to some clipboard and BMP-related libraries ...

Sorry, I had been working on another post and for some reason the link to the clipboard library must have stayed in my clipboard (how is that about the clipboard causing a problem about a link to a post about the clipboard ) despite my different intentions. It should be fixed now.

[asbo]

Sorry, I had been working on another post and for some reason the link to the clipboard library must have stayed in my clipboard (how is that about the clipboard causing a problem about a link to a post about the clipboard ) despite my different intentions. It should be fixed now.