LabVIEW
Running console application from LV7.1 problems
Hello,
I have a strange issue. I'll try to explain my problem as best as I can. I have a console application that has some text outputs in the console window (Like a load bar and some other data). This is working nicely if I call it from cmd window with the syntax [path][application name].exe[space][parameter1][space][parameter2][…]. So it displays the correct texts and what not. I have to call this application from LV. So I build the following string:
cmd /c "%s"
Where %s is the previously mentioned syntax. Than I pass the value to System exec.vi:
So the problem is – if I just use the created string (copy out of CMD string indicator) and give it to “Run” in windows it works. But if I use the VI it pops up a cmd window that is completely blank. It does work in the background (about 25% cpu load + after a while I get the return value) but nothing is visible from the run. So I guess LV does not exactly just gives my string to windows but does something with it and I can’t seem to figure out what.
Does someone know how I could get the cmd window to display the texts from the application?
Thank you in advance!
What happens if you simply put %s (the actual command and parameters) without the cmd /c "%s"?
Often that's enough.
And of course if you make clean code, it's easier to spot problems.
Search LabVIEW like a graph! Hi,
sorry about the code - the last string formatting was put there later and since the code is really complicated I do not wish to “move” the other sections. It took about 3 days to clean it up to this level and I have no further time for that since the functionality is not yet properly working. Will clean up after it is working as intended…
If I use simply the string than a CMD window pops up with the application path as it’s name and it does not work. Meaning it just stays idle with 0% cpu load. After about 30 minutes (way past all timeouts) I close it and it generates a random error number. How it is currently with “cmd /c “%s”): a regular cmd.exe window is popped up and it starts what it should properly (but as mentioned, no text displayed).
As a reply to Bob_Schor: Sadly I can not attach any VIs. As company policy it automatically has company related info hardcoded in it (like my e-mail address) and I can not remove this data. Legally I think it would mean I am leaking software code since it is made on company PC -> It is the property of the company. + I can not create any kind of exe that would have similar calling method that someone could use for testing. At home I have no LV7 + not even the same os.
I attached what I could safely – besides only the system exec.vi is needed with a single string as code (+2 bool constants). It should not take any more time to create it than me giving away the VI and someone adapting it to his / her system…
I tried what you proposed – used dir to go to a network folder. What happens is that the cmd window pops up and instantly closes with return code 0. But this happens if I use no parameter, and also if I use /c or /k. So I am just even more confused.
Tested strings:
cmd /k "dir [path]"
cmd /c "dir [path]"
cmd "dir [path]"
cmd /k dir "[path]"
cmd /c dir "[path]"
cmd dir "[path]"
cmd /c dir [path]
cmd /k dir [path]
cmd dir [path]
Always the same – pops up, disappears, return code 0…
And what would be the path you are trying to use? [path] isn't VERY helpful in this context.
As you are almost certainly running Windows 10, and at that almost certainly the 64-bit variant of Windows you have something called file system redirection when running a 32-bit process on such a system. Starting cmd.exe from a 32-bit process will start the 32-bit variant of cmd.exe from C:\Windows\SysWOW64. This process as a 32-bit process will be subject to the same windows files system redirection, so any path that references a so called 64-bit location such as "C:\Program Files\..." will be "helpfully" redirected by the Windows kernel to its 32-bit counterpart "C:\Program Files (x86)\..."
E voila, trying to dir for instance "C:\Program Files\My Super App" will instead dir "C:\Program Files (x86)\My Super App", which is likely to not exist at all and even if it does it probably is not what you want anyways.
There are Windows API calls to temporarely disable file system redirection for a process but using them can throw a wrench in other things inside that process that depend on the file system redirection to be done the way it is normally done.
Just to mention, you will never get any output string until the process is finished. At least not from the System Exec. If the process doesn't stop, you won't get a return string. SE is not an interactive shell...
You'd need some sort of pipe for that.
I have win 7 2009 service pack 1 64bit enterprise.
The path is a network location in this format: \\[location pc standard name 4 letters and 4 numbers]\[folder name]\[folder name]\[folder name]\ -> It is only 40 characters long with some basic folder names (like ABC_BC). Obviously I am not trying to access anything on a local pc since everything is on network drives. LV is locally installed though but I compile the VI into exe and must call it from an other application on the PC it will be used on. There only runtime engine is available. Normally I connect to the pc via remote desktop and run things directly on it. (though apart from runtime engine everything is on the network)
For local testing I access the same folders + everything is already where it will be used later. The path is built by labview and not given directly by me -> See one of my other forum posts where I created a VI that looks up where the VI / exe is and uses that as path. It differentiates also if it is in development environment or run as application. The whole thing can also be run via TCP (than it uses direct IP addresses) so the path might not be the correct terminology but it should not matter in this case. In TCP use case it is something like “[PC name 4 letters 4 numbers].corporate.[name].com” and it works that way too. Though I have not yet tested it to 100%. This is why I did not want to get into path details since they should not matter with this problem. But correct me if I am wrong.
As I said – the application DOES run so there is no problem with how to access it. The problem is that the text interface is not displayed and I do not know how to make it visible.
About the dir command I tried to access the same folder where the exe is though there I did not use the aforementioned path generation. Just ran the whole thing and copied the path from what LV generated.
Hello again,
I just gave a try again to the same what you did - and it just pops up and instantly closes. So there is something going on for sure. I have LV2015 also installed. I tried checking system exec there but it is password locked by NI. However the LV7.1 version is not so I had a peak. It basically only has 1 thing in it that is Code Interface Node. However the onboard help only has one sentence:
This is everything available in the help too. Lovely. I found this document though: http://www.ni.com/pdf/manuals/320539d.pdf Will give it a go and check what is up here.
I also have a fear that our IT department has some magic mumbo-jumbo going on. There are some problems that our “custom” windows causes for us but so far I could not get any usable info from them. Will come back as soon as I know something useful. Though any comments that would help are still appreciated.
Any tips / ideas what else I could look into?
2018 has a bit more, but noting about why your situation doesn't work.
Try starting LV as administrator. Being admin isn't the same, you need elevated rights.
