Jump to content

Running a LabVIEW EXE from the Console


Recommended Posts

Ok, so this is a strange application, but I need to build a little exe that can be called from any scripting language (in this case Python) and can accept command line arguments and write its output to StdOut. So far, I have accomplished all this using the standard LV properties for getting the command line args and using some kernel32.dll calls to write to the StdOut of the cmd.exe console window.

Where this breaks down is when calling a LabVIEW exe from the console, the console thread is not blocked while the exe runs. So, the result is the console returns back the command prompt and then a little while later my exe sends the data to the console and it just appears where ever the cursor is currently at. :(

So, I need to figure out a way for my exe to steal the thread of the console and block it until it is done writting its output.

Any gurus out there have a idea even where to start figuring this one out? It has me baffled. :frusty:

BTW: if you also have a .NET solution for writing to the stdout instead of the old school kernel32.dll solution, I would love to see it.

thanks for the help and/or sympathy.

-John

PS. If you are wondering why the *$@#$! anyone would want to do this, basically it comes down to the need for some non-LabVIEW DEVs to control some cFP hardware over Ethernet and the only way I know how to do this is using LOGOS via DataSockets and that only works in LabVIEW!

  • Like 1
Link to comment

I don't have any thing to add since I've never been able to accomplish what you are asking for. I've also wanted to write a command-line LabVIEW program from time to time and I've always had difficulty with the StdOut as well. Sounds like you were able to get farther than I ever did. I always ended up outputting to a new command line window instead of the one it was ran in. If you don't mind could you post the code that you've got so far?

Link to comment

BTW: if you also have a .NET solution for writing to the stdout instead of the old school kernel32.dll solution, I would love to see it.

As far as .NET goes, you can use System.Console to control your console window (write, write line, position cursor, etc.) but unfortunately I think you still need one API call to kernal32.dll for either AllocConsole() or AttachConsole() before any .NET calls.

You can then either use asbo's solution using start or use the props/methods of System.Console to position the cursor and "erase" part of the screen before writing your text if you're just wanting to make it look nice. The latter is a little hacky.

If there is a pure .NET solution, I haven't found it, so if you figure it out let us know.

Incidentally, in Linux I always just used the 'Write to Text File' function with a path of dev/stdout and it worked great.

-Scott

Link to comment

Sweet! That solves it. So, now we can write a LabVIEW console app!

Here is the VI that let's you write to the StdOut of the calling console:

Awesome! Do you have any code that will create a console window for output if there isn't a parent? Certainly would be handy for development.

Link to comment

I tried to call this VI (built into an EXE) using System Exec from LabVIEW. The output does not show up in the STDOUT of the System Exec. It seems this only works when there is a console window (which is nice, but doesn't allow the EXE to be called from other applications in a way that lets them read the STDOUT). Did I miss anything?

Link to comment

I tried to call this VI (built into an EXE) using System Exec from LabVIEW. The output does not show up in the STDOUT of the System Exec. It seems this only works when there is a console window (which is nice, but doesn't allow the EXE to be called from other applications in a way that lets them read the STDOUT). Did I miss anything?

Interesting. I haven't looked into it any further but if you use the .NET methods, it does work with System Exec. I've attached an example (LV20009) which allows writing with both kernel32 dll calls and .NET. The writes using the dll will not appear in STDOUT as you found, but the writes using .NET will.

Also, neither method as used works with redirection or piping, but it might be possible to get that to work as well if someone wanted to investigate it.

IIRC, The method in Linux of writing directly to dev/stdout with the file functions does support redirection at least (never tried piping).

-Scott

Write Std Out Example.vi

Link to comment

I tried to call this VI (built into an EXE) using System Exec from LabVIEW. The output does not show up in the STDOUT of the System Exec. It seems this only works when there is a console window (which is nice, but doesn't allow the EXE to be called from other applications in a way that lets them read the STDOUT). Did I miss anything?

Well, you got me stumped. I have tried allocating a console, tried geting the PID of the exe and then attaching to that console and tried not attaching to any console and I cannot get the LV System Exec call to work. :frusty:

This exhausts my knowledge of windows hacks to do something like this. I will leave it to others to sort this out. It's just another example of what a PITA windows programming is.... :throwpc:

-John

Interesting. I haven't looked into it any further but if you use the .NET methods, it does work with System Exec. I've attached an example (LV20009) which allows writing with both kernel32 dll calls and .NET. The writes using the dll will not appear in STDOUT as you found, but the writes using .NET will.

Also, neither method as used works with redirection or piping, but it might be possible to get that to work as well if someone wanted to investigate it.

IIRC, The method in Linux of writing directly to dev/stdout with the file functions does support redirection at least (never tried piping).

-Scott

I just tried your method using .NET to write the string. While this continued to work from the command line, I was unable to get this to work from the System Exec call. I can't seem to figure out what I am missing.

Any chance you know of a was to perform the AttachConsole within .NET? It would be nice to get rid of any DLL calls...

Link to comment

I just tried your method using .NET to write the string. While this continued to work from the command line, I was unable to get this to work from the System Exec call. I can't seem to figure out what I am missing.

Any chance you know of a was to perform the AttachConsole within .NET? It would be nice to get rid of any DLL calls...

I just tried building you exact code into an exe in LV2009 (instead of replicating the functions in 8.6.1 like I did above) and I still cannot get anything returned to the StdOut of the System Exec call from within LV. Are you sure you got that part to work?

Also, I think this might be related to the fact that the redirection and piping does not work.

-John

Link to comment

Any chance you know of a was to perform the AttachConsole within .NET? It would be nice to get rid of any DLL calls...

No. If there is a pure .NET way, I haven't found it yet. I haven't searched real hard, so it may still be out there.

I just tried building you exact code into an exe in LV2009 (instead of replicating the functions in 8.6.1 like I did above) and I still cannot get anything returned to the StdOut of the System Exec call from within LV. Are you sure you got that part to work?

Positive. I just tried it again to be sure. I'm on XP. To be honest, I was a little surprised that it did work. More about that below.

Also, I think this might be related to the fact that the redirection and piping does not work.

I don't pretend to fully understand it yet, but my interpretation is that you're not really writing to stdout, but to the console which I think is a distinct but subtle difference. That is why I believe (at this point) that piping and redirection don't work, but also why I was surprised that the .NET WriteLine output appeared on stdout of System Exec (at least for me). There's a contradiction there, so more investigation of what is really happening is needed.

-Scott

Link to comment

I don't pretend to fully understand it yet, but my interpretation is that you're not really writing to stdout, but to the console which I think is a distinct but subtle difference.

I would agree with you. The original problem remember was that the LV program would execute and then a few seconds later (when it was done) it would output to the command line. In the few seconds that the program ran the user could type stuff into the command line, and then the program would finish and append to what the user has already typed.

If an application is running I would think it would lock the command prompt from more user input unless it requested some. So the theory that the application is just doing a console write, instead of stdout may be correct.

Link to comment

Positive. I just tried it again to be sure. I'm on XP. To be honest, I was a little surprised that it did work. More about that below.

I don't pretend to fully understand it yet, but my interpretation is that you're not really writing to stdout, but to the console which I think is a distinct but subtle difference. That is why I believe (at this point) that piping and redirection don't work, but also why I was surprised that the .NET WriteLine output appeared on stdout of System Exec (at least for me). There's a contradiction there, so more investigation of what is really happening is needed.

Can you post your exe? I have tried building an EXE from your VI in LV2009 and I cannot replicate what you are seeing with regards to the System Exec.

thanks,

-John

I would agree with you. The original problem remember was that the LV program would execute and then a few seconds later (when it was done) it would output to the command line. In the few seconds that the program ran the user could type stuff into the command line, and then the program would finish and append to what the user has already typed.

If an application is running I would think it would lock the command prompt from more user input unless it requested some. So the theory that the application is just doing a console write, instead of stdout may be correct.

Yes, the original issue was how to block the console while the app ran. And using the 'start /wait' command solved this. But, I think you are right about not really writing to StdOut. I wish I knew a Windows expert who I could ask...

-John

Link to comment

Can you post your exe? I have tried building an EXE from your VI in LV2009 and I cannot replicate what you are seeing with regards to the System Exec.

Here it is. I've called it from System Exec in both 2009 and 8.6 and in both cases I get output in the 'standard output' indicator. If it still doesnt work for you, can you add any info about your setup.

-Scott

testso.zip

Link to comment

Here it is. I've called it from System Exec in both 2009 and 8.6 and in both cases I get output in the 'standard output' indicator.

The .NET solution works great for me (I can call the EXE using System Exec in LV 2009 on Windows 7 64-bit, and I get the standard output returned to System Exec, just as expected). Sweet!

Thanks,

Link to comment

Here it is. I've called it from System Exec in both 2009 and 8.6 and in both cases I get output in the 'standard output' indicator. If it still doesnt work for you, can you add any info about your setup.

-Scott

No joy here. I cannot get anything back from the System Exec call. It does open a console window and I can see the output in the window as I press the write buttons but when I choose exit and close the app's window, nothing is returned to the calling LV VI. Do you have anything special in your exe's ini file?

The .NET solution works great for me (I can call the EXE using System Exec in LV 2009 on Windows 7 64-bit, and I get the standard output returned to System Exec, just as expected). Sweet!

Thanks,

Weird. I get nothing under XP when calling from either LV2009 or 8.6.1. Maybe this is an XP issue. Can you try this on an XP machine and confirm?

  • Like 1
Link to comment

No joy here. I cannot get anything back from the System Exec call. It does open a console window and I can see the output in the window as I press the write buttons but when I choose exit and close the app's window, nothing is returned to the calling LV VI. Do you have anything special in your exe's ini file?

Weird. I get nothing under XP when calling from either LV2009 or 8.6.1. Maybe this is an XP issue. Can you try this on an XP machine and confirm?

Ok, Now I see what I did wrong. I was calling it like this: 'cmd.exe /c "myapp.exe"'.

That does not work. Interestingly, however, something like this: 'cmd.exe /c dir' does return data to the stdout of System Exec. So, again it appears that you can attach to the console of the caller but System Exec is more like the 'run' command. Still does not explain why redirection does not work.

Link to comment

No joy here. I cannot get anything back from the System Exec call. It does open a console window and I can see the output in the window as I press the write buttons but when I choose exit and close the app's window, nothing is returned to the calling LV VI. Do you have anything special in your exe's ini file?

Weird. I get nothing under XP when calling from either LV2009 or 8.6.1. Maybe this is an XP issue. Can you try this on an XP machine and confirm?

No, nothing special in the ini. In fact you don't even need the ini. I'm on XP and Jim has tried it on Win7.

What are you using for the command line in System exec? I wouldn't expect a console Window to open (I don't get one), which leads me to believe you are using cmd /c or start on the command line. Just try the path to the exe and see if that works.

-Scott

EDIT: I see you've already figured it out. I'm working on the redirection issue. If I get it figured out, I'll post the solution.

Link to comment

Ok, Now I see what I did wrong. I was calling it like this: 'cmd.exe /c "myapp.exe"'.

That does not work. Interestingly, however, something like this: 'cmd.exe /c dir' does return data to the stdout of System Exec. So, again it appears that you can attach to the console of the caller but System Exec is more like the 'run' command. Still does not explain why redirection does not work.

Ya, I use the full path of the EXE as the command.

Link to comment

Ya, I use the full path of the EXE as the command.

So, when calling this from a real console (cmd.exe) you need to use the start command to make the console wait. But, the start command is it's own app so either the AttachConsole does not really attach you to the cmd.exe's console or the GetStdHandle is not the cmd.exe's StdOut. So, redirection fails.

What about using WriteFile instead of WriteConsoleA? That might make the redirection work.

Link to comment

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.