Jump to content

System exec with a timeout


Recommended Posts

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

post-2399-0-26786400-1292600258_thumb.pn

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

Link to post

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.

Link to post

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

Link to post

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.

Link to post

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.

  • Like 1
Link to post

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

Link to post

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

post-689-0-15450300-1292884190_thumb.png

Link to post

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 ;)

Link to post

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:

post-11742-0-61568300-1292884986_thumb.p

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

Link to post

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 :rolleyes:) despite my different intentions. It should be fixed now.

Link to post

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 :rolleyes:) despite my different intentions. It should be fixed now.

:lol::beer_mug:

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.