Controlling the STDIN STDOUT of a legacy application in LabVIEW

[eric.atherton]

I have a legacy DOS based program that runs in a command line interface in Windows.  The normal use is that an operator types in a command, looks at the result, then types in another command depending on the outcome.  I need to launch this application, KEEP IT OPEN, and send/receive commands from the CMD Line Interface WHILE IT IS STILL OPEN.

Since I need to keep this program open, I can't use the normal System Exec.vi that allows for a single STDIN/STDOUT.

Has anyone else done this?  I have heard that it's possible using PERL, but I'm trying to do this in native LabVIEW, if possible.

[rolfk · Accepted solution]

On Linux you could use the Pipe VIs that LabVIEW comes with. For Windows you can try the OpenG Pipe library.

Disclaimer: That Pipe library works for me but it is not fully debugged software, so beware when using it in a production type environment.

To install the attached package you best use the VI Package Manager. 

Message Edited by rolfk on 04-02-2010 08:24 AM

[smercurio_fc]

Another option is to use the Windows API as I showed in this example. Note that the end of the thread has an update on pasting text into the command window.

You'll have to decide whether it's better for you to use pipes or the method in my example.

[eric.atherton]

Thanks so much for the Pipes concept, that worked perfectly!  Just to clairify for anyone else in the future, in the VI Package Manager, it is compiled for LabVIEW 7.x, so it may not show up in 8.x or 9.x.  But once you get by that, it works great!!

Thanks,
Eric

[labview4steve]

Hi Eric (or anyone else who has done it before),
I see you had some success and I was hoping you may be able to return the favour....
I hven't had any success using the open G other than the standard stuff that system Exec.vi can do..

 I am currently trying to do the EXACT SAME THING that you were trying to do but was unable to get the OpenG pipes library to do what I wanted. ie send a command, keep the instance of cmd prompt open (at least in memory if not visible), and be able to send and retrieve commands

I've installed the oglib_pipe-1.0-1 library indicate above, so that's fine.

I can currently use the "open the system command.vi" and get the process ID and Pipes reference for std Output, std Input, and standard err and I can use the pipes reference to read the std Output by using the pipes reference for the standard Output with the "read from pipe" vi - I use "read-write" as the option.so that's fine, 

but I CANNOT seem to use the Standard Input or Standard Output Reference with the "Write to Pipe.vi"
and hence I cannot send data back and forth between my labview code and the external perl code.

is it possible for you to post the code to the ni.com page that you used when you managed to do this, so i can see an example of how it was done?
or at least just some instructions?

Cheers

I've attached the labview example I've been using just to test how each function works.. feel free to tinker with it if needed... 

[rolfk]

Can you try the eaxample here? Does that work?

Trying to write to the standard output should definitely not work. Those pipes are unidirectional. Read/Write means simply that  standard input AND standard output will be attached too and return according pipes. If you specify read only

[Dhakkan]

---

@rolfk wrote:

On Linux you could use the Pipe VIs that LabVIEW comes with. For Windows you can try the OpenG Pipe library.

Disclaimer: That Pipe library works for me but it is not fully debugged software, so beware when using it in a production type environment.

---

Even after a decade+ worth of LabVIEW and OS releases, it works with LabVIEW 2023 (32-bit) on Windows 11! Is it possible to make this library's DLL source code publicly viewable?

[rolfk]

It always has been. it’s part of the OpenG Toolkit repository on Sourceforge.

[Dhakkan]

Thanks! I just did an internet search. It's in the c_source folder in this link, I guess. (Shame on me - In all my years of using LabVIEW, I was never curious about where OpenG source code resided.)

[rolfk]

Yes that’s it. All the files with name ogpipes.*

Rest is for a simple server and client for testing.