How to pass input to a DOS executable that is running in parallel to a VI

[carlsch]

I am using System Exec to call a DOS executable that then runs in the background in parallel to a VI. While it runs, the executable is controled by commands that are typed to it, and I need to be able to pass those commands to the executable during the duration of my VI's execution. (This is different from one-time parameters that I can pass from the command line before running the program.)

Other threads on this board suggest passing input and output back-and-forth with executables called using System Exec by using a temporary file which is periodically queryied by both the VI and the executable. In my case this is not feasible since I need to be able to do this very quickly and, at some times, often.

Does anyone have a solution for directly delivering my (text) commands to the DOS executable running in the background? I did find an approach posted by smercurio_fc at: http://forums.ni.com/t5/LabVIEW/URGENT-How-we-read-stdout-directly/td-p/801983  It sounds promising but I am not sure whether this would solve my problem, as I couldn't see the solution (can't open the examples as they are written for LabView 8, and I am running Version 7.1.).

Thanks in advance for any leads.

[550nm]

Hi carlsch,

      Another option might be to open a UDP connection (or two) between applications - it's very fast and easily event-based.  Other threads, here, suggest something called a "Memory Mapped File" which sounds faster than a disk file (not sure whether that's what was being considered.)  Similar to UDP, a serial connection using couple of COM ports (via USB adapters?) could work, though, may be relatively slow...

Luck/Cheers! 

[rolfk · Accepted solution]

In the OpenG libraries is a library that allows to open a command line utility like with SystemExec and gets its standard input and output as streams that can be read and written too. It 's still Alpha status kind of since there need to be some more tests done on various Windows versions, but it works for me so far.

Check out this thread.

[carlsch]

Hi RolfK,

Thank you for your reply--and for building OGPIPE, it's a great service to the community. By all accounts this is exactly what I need. The problem is, I can get it to install and can call the VIs in the library, and "OGPIPE Open System Command" works fine, but I can get the following error when I call "OGPIPE Write to Pipe" as in the example below: "Error 8 occured at WritePipe (...) File permission error. You do not have the correct permissions for the file". This does not occur when I call OGPIPE's Read function.

This issue occured when I tried it in both LabView 7.1 and LabView 2011 on two machines running Windows XP SP3.

I thank you in advance for any suggestions you may have. 

Carl

[rolfk]

Well you try to write to the standard output! That can't work. I realize that the naming can be confusing, but no matter what you do, it is wrong for some. The naming I chose is from the view of the command line tool and that writes to the standard output and standard error and reads from the standard input. For LabVIEW that means you can only Read from the standard output and standard error and only write to the standard input.

[carlsch]

Yes of course, sorry for being thick.

I think I'm almost there, but it's still not quite working. For some reason, when I call cmd.exe (or my own executable) I never get a prompt back; that is, it opens cmd (or it runs my executable normally up until the point where it needs user input) but the window never shows anything more than a blnking cursor (that is, no "C:\>" prompt when I call cmd, or my executable's prompt when I call that, as shown below). The OGPIPE_Write VI has no effect, although I am no longer getting any error messages, and the VI outputs the number of bytes that have supposidly been written. I've tried all sorts of combinations (quotes, calling cmd \c first, etc.) and somehow I can't get this to work. This is also true when I use the System Exec VI, and I am wondering whether perhaps there is a LabView option, or even a Windows option that I haven't set properly.

Again, any guidance on this much appreciated.

[rolfk]

Hmmm, the command line window won't be a good debugging help here. The OGPIPE library disconnects the standard IO for the application from the console and redirects them to the pipes. This means that you will not see the characters going over the pipes in the console window. Since you only connect the standard input pipe you might be able to open the command line tool for Write access only, and in that way send comamnds to the tool, but read its response on the console. Or you need to also add a Pipe Read to the standard output refnum, but make sure to use dataflow dependency so that the read is executed after the write.

[carlsch]

I see. So I followed your suggestion and added a Pipe Read to the standard output so that I can read the output in the VI's front panel. Encouragingly, now I see the prompt--either the standard text that comes out when you run "cmd", or my own DOS exectuable's prompt when I call that (image below shows result when I call "cmd", and VI attached below). Moreoever, the Pipe Read VI outputs the number of bytes read.

However, even though the Pipe Write outputs the number of bytes written, it does not seem to have any discernable effect, either when trying to list the contents of the directory as below, or when inputing commands to my own DOS program. So it seems the issue is how I'm using Pipe Write. (This example is in LabView 7.1, but the problem is the same in 2011.) I've tried a number of combinations--with quotes, without, using \n, \r, a combination of both, all to no avail.

Once again, I am very grateful for your help in this matter.

[Eric-M]

Hey Carl,

On your string constants that you plan on using for writing, right click on them and select '\' Code Display.  This will show the \ format that is actually being sent.  In the case of the example you are sending, the actual string being sent across is "dir\\r\\n", rather than "dir\r\n".

Hope that helps,

[carlsch]

Terrific, that works--thank you both to RolfK and Eric-M for helping me through this.

Posting the VI for future users. (Made in LabView 7.1 running on Windows XP.)