Not able to write into console when VI hasn't been called with CMD

[77maxmustermann]

So I created a basic Vi that search for the current CMD process that's open and then write messages to it.

My problem is that my VI only works when I call it with CMD even though it should logically work when I open it manually as long as a CMD.exe is already Open.

You'll find the VI attached to this message.

Simply go to CMD.exe type C:/..../your_vi_location/Prototype-02.vi and the VI should type success in your command.

But then try letting the CMD.exe open and compile it ,sadly it wouldnt work.

Can someone tell me why is this the case and how can I fix it?

Thanks

[lukas.wiesner]

Hello,

I tried to reproduce the steps which you posted.

When the CMD is not open at all I was reciaving an error 1172, which is probably expected behavior.

When I opened CMD and run the VI it runs without any problem, but I did not get a "Success" anywhere.

The same result is when I try to run the VI through the CMD. It runs fine but it does not return "Success" anywhere.

Lukas

[77maxmustermann]

My Bad I should've said this important thing which is : Every instance of Labview need to be closed before you do it.

Then simply go to CMD and type "C:\Users\......\Prototype02.vi" and it will work.

[playerm1]

I don't have a solution, but here are my observations:

As long as the LabVIEW IDE is opened from the CMD line, the VI will be able to obtain a handle to that CMD line instance, and will show "success".  You shouldn't have to shut it down after each run.  If the LabVIEW IDE is opened normally through Windows explorer, it seems that the "ToInt32" process handle invoke node is unable to obtain a valid handle to the CMD line, even if one or more CMD line instances are opened (returns a 0).  Even though this invoke node is not returning the desired output, it is also not triggering a LabVIEW error.  I suspect that there a step missing related to the CMD line process handle that is taken care of implicitly when opening the LabVIEW IDE through that same instance of CMD line.

[lukas.wiesner]

Yes, I can observe the same behavior. 

Which steps do you suspect are missing?

[playerm1]

Maybe a step that points to a specific instance of CMD since multiple can be opened at a time.  Maybe an authentication or permissions-related step.  Maybe a user-privilege elevation step.  It's hard to say, but it looks like there are a large number of options available on the invoke nodes.

[lukas.wiesner]

Hello,

Because of the problem mentioned above, I would try to suggest you rather using System Exec VI to call a CMD from LabVIEW.

It might resolve your problem.

Lukas

[77maxmustermann]

The problem is that I want my VI to write back to the already open CMD. It works fine in normal circumstances but I have to make Unit tests for it. Meaning the tests need to be automated

[lukas.wiesner]

Hello, I could not find a way how to write back to already opened CMD. This is the limitation of OS as there does not exist anything as ID of each CMD. LabVIEW simply doesn't know which CMD to write back to.

The only way for this could be to create the architecture in LabVIEW. You would need to have a VI with System Exec VI, which would be always loading dynamically different VIs to write their parameters to the CMD. The trick is that it would be the whole time the one same CMD from System Exec VI.

Lukas