System Exec.vi

[sonduc_tran]

Please help. Thank you in advance.

Hardware: Win7 64bit, AVRISP2

Software: LV2018, Atmel Studio 7, ATbackend, ATprogram.exe

Facts:

-Using DOS Prompt Command > WORKS.

-VI in Win10 >> WORKS.

-VI in Win7 64bit >> ERROR.

-Tried using BAT file > Same results.

[ERROR] An unexpected error occurred when executing.
Traceback (most recent call last):
File "atmel\atprogram.py", line 48, in run
File "atmel\avr\cli\commandline.py", line 54, in execute_commands
File "atmel\avr\cli\commandexecutor.py", line 52, in execute_commands
File "atmel\avr\cli\resourcemanager.py", line 44, in prepare_resources
File "atmel\avr\cli\resourcemanager.py", line 51, in _prepare_resource
File "atmel\avr\cli\resourcecontainers.py", line 54, in allocate
File "atmel\avr\cli\backend.py", line 134, in start
File "subprocess.py", line 702, in __init__
File "subprocess.py", line 823, in _get_handles

WindowsError: [Error 6] The handle is invalid

[croohcifer]

First, a question:  When you state "Using DOS Prompt Command > WORKS", is that on Win7 or Win10?  If that's on Win10, then first try using the command line in Win7 to see if you can replicate the behavior you're seeing in LV on Win10.  If the cmd works on Win7, then proceed:

The first step is to make sure you're actually doing the same thing in the command line and in LabVIEW, which you're not.

1. You included the .exe extension when running in the command line but not in the LabVIEW code.  This is a small difference, but without the extension, you're relying on the right command path being included in your environment variables, which might not be the case on all machines.  It's probably safer to always point directly to the .exe file if you want a specific version in a specific installation directory to always run.
2. In the command line screenshot, you actually changed your working directory to <atbackend>, but you didn't in the LabVIEW code.  This shouldn't really matter, but it's worth pointing out for completeness.

In other words, to match your command line screenshot, you need to do this:  

Finally, read the detailed help of the System Exec VI.  Using this VI is NOT the equivalent of running something directly from the command line.  The help specifically states "To use a command that must be executed directly from a command prompt window, insert cmd /c before the command."  In other words, try "cmd /c atprogram.exe list" as your command line input in LabVIEW.

I suspect that one or more of these changes will resolve your problem.  If not, then look at the command line window to see what is different when running directly in the command line vs. from LabVIEW to see if there are any differences whatsoever.

As a final comment, the Windows 7 and Windows 10 command lines are different applications and behave slightly differently, so it doesn't surprise me that your code works on one OS but not the other.  You should always expect differences in behavior between operating systems when writing code in any language.

Let us know if any of the above fixed the issue.

[balexand]

Try wiring an end of line constant to the standard input terminal of the System Exec VI.  I have seen a behavior where there is no stdin handle available from the child process if you pass an empty string to the standard input terminal or leave it unwired.

[sonduc_tran]

First of all, thank you for your prompt response.

I have tried all your suggestions and the problem remains.

1. Using DOS Promp Command works on both WIN10 and WIN7.

2. I have tried both, with and without "exe" extension >> same error.

3. I have tried matching the command line per your suggestion >> same error.

4. I tried this and get an error. 

Also, in the LV help, 

Note  Do not use working directory to locate the executable you want to run. working directory applies to the executable only after it launches.

[croohcifer]

Good catch on the working directory.  You may still need to set it if the underlying code requires a specific working directory, though.  Can you go to the lines in the python scripts called out in the error and see what is causing the issue?  What does Line 48 in that first .py file actually do?