.NET Process STDOUT / STDIN Interface to CLI application

[pherrmann90]

Working on interfacing with a CLI application our firmware team uses for hardware testing. Currently working with .NET Process calls with StreamReader Read functions for reading STDOUT. Unfortunately, it looks like Peek and Read block whenever there's nothing to read on STDOUT, rather than return -1 as expected.

Was looking into implementing an Asynchronous Read instead, as I've read on other .NET/VB forums that this is an issue outside of LabVIEW as well. However, I'm struggling to implement this example:

https://msdn.microsoft.com/en-us/library/system.diagnostics.process.beginoutputreadline(v=vs.110).as...

specifically the 

// Set our event handler to asynchronously read the sort output.

 section. Not sure if I just don't know what to look for in the .NET property/method/constructors in LabVIEW of if this isn't possible in LabVIEW at all.

Attached is what I've got working so far, but it hangs at times when the STDOUT stream is empty.

Hoping someone can take a look at the MSDN example and see if there's a way to implement this in LabVIEW with .NET calls.

Thanks,

Preston

[tyk007]

You don't seem to be following the steps listed in the MSDN link. When you are performing the output stream read aynchronously you do not use the synchronous Read / Peek methods (which, as you said, don't return unless there is something to return). Have a look at Step 3 mentioned in the link - you need to register for an event that indicates that data is available (OutputDataRecevied). In LabVIEW, this means dropping a Register for Event node and adding a callback that will be executed by the CLR thread when data is received. The callback signature includes an instance of a DataReceivedEventArgs object that has a Data property you can read.

Attached is a starting example I whipped up (though I didn't test it, I'll leave that to you) that performs this action. Since the callback VI is called by a CLR thread, and the CLR thread does not return to enable the next execution of the event until the callback is finished, I recommend piping the output data string to a Queue for later processing in a Read VI or similar (this is what my example is intended to do) so that the callback VI is executed as quickly as possible and does not block.

[pherrmann90]

Hey tyk007,

Thanks for the response. I realize that my original example was missing Step 3, and your example explains exactly what I was looking for.

I tried running your example with a ping.exe command (google.com -n 20 as my arguments). I figured this is a pretty straightforward command and should spit out data on STDOUT regularly for a short amount of time. While it looks like the Process starts OK (I can see it in Task Manager) I don't see any events triggered in the event case structure or data read from the Dequeue element (both just time out).

Is there something missing from my end you were expecting me to implement? This is skirting right on the edge of what I'm comfortable and familiar with in LabVIEW, and I don't have much experience with .NET except what I can glean from basic C/C++ knowledge.

[tyk007 · Accepted solution]

Have a look at an updated example. I used your ping as a demo (via cmd /c). This uses the instance constructor to create the process, configure startinfo and raising events (to receive the Exit event, something additional I suggest you use to detect the cmd line app exit). 

This works on my machine and I receive the ping responses dequeued in the Read that are piped to a string indicator.

[pherrmann90]

Thanks tyk007!

This is definitely working on my end now. I'll need to do some reading on .NET to get a better understanding on how exactly this works, but this is a great jumping-off point.

Much appreciated!

-Preston

[tyk007]

If you are interested in the "internals" of the classes you are using, the .NET Framework source code is documented online (http://referencesource.microsoft.com/). Digging through this a little might also be of interest and answer a few questions. Good luck!