Interactive command line using .NET

[bjustice]

I threw this together, and maybe someone will find it useful.

I needed to be able to interact with cmd.exe a bit more than the native system exec.vi primitive offers.  I used .NET to get the job done.  Some notable capabilities:

- User can see standard output and standard error in real-time
- User can write a command to standard input
- User can query if the process has completed
- User can abort the process by sending a ctrl-C command

Aborting the process was the trickiest part.  I found a solution at the following article:
http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880

The ping demo illustrates this capability.  In order to abort ping.exe from the command-line, the user needs to send a ctrl-c command.  We achieve this by invoking KERNEL32 to attach a console to the process ID and then sending a ctrl-C command to the process.  This is a clean solution that safely aborts ping.exe.  The best part about this solution is that it doesn't require for any console prompts to be visible.  An alternate solution was to start the cmd.exe process with a visible window, and then to issue a MainWindowClose command, but this required for a window to be visible.

I put this code together to allow for me to better interact with HandbrakeCLI and FFMPEG.  Enjoi

NET_Proc.zip

[Qianhao]

Thx for your sharing sir! But at my current project, I got the a EXE file, and I would write some commands after i execute it, and i can't finished it with SYSTEM Exec or your tool, could you pls help me to figure out it ? the yellow part below are the commands, thx again!

D:\DESKTOP\VIG\BLE>BLE_GET_RSSI.exe
Loading...
<<READY>>
Connect FDB06556E922
<<READY>>
7C1ABEE86B33
Connectng
Connecting to FDB06556E922, Device name: VIG2_BLE_FDB06556E922
Connected to FDB06556E922
Discover Complete
SEND VIG_BYPASS
TX: VIG_BYPASS
<<READY>>
RX: MAC CHK OK
SEND soc_ver?
TX: soc_ver?
<<READY>>
RX: 0.762
quit

D:\DESKTOP\VIG\BLE>

[Niatross]

Thanks for posting this. I am trying to use FFmpeg in LabView as well (Proving to be a real pain but this has made it a lot easier!!)

Do you find that closing the FFmpeg isntance sometimes causes LabView to crash, especially if FFmpeg hasn't started processing frames yet so sending q doesn't work (Whilst it is waiting for a stream for example)

My shutdown process is to send a'q' character, if the process has exited that's fine, if not send a ctrl-c. In this case I am finding that whilst the FFmpeg instace ends the wait on exit either hangs indefinitely or causes LabView to crash and close. 

This is the most stable implementation I have managed so far.

Any suggestions on better ways of closing FFmpeg?

 

Also, have you worked out a way of sharing data between FFmpeg and LabVIEW. (Use LabVIEW to provide image data or get image data into LabView) I know you can use the stdin and stdout. I haven't tried stdin for providing image data to FFmpeg yet but stdout does have a tendency to loose data, There is something blocking your stdout callback code causing it to miss stdout events (Or it just takes too long) I have had to resort to TCP mjpeg streams directed to 127.0.0.1.

 

[bjustice]

I've not run into a situation where I've needed to get the actual image data into LabVIEW.  I've mostly needed to handle file streaming to/from disk.  It would be easier to use files on disk as a middleman between LabVIEW and FFMPEG.  If you need a live streaming solution to LabVIEW, then you probably need a different technology

I've never run into the situation where I've needed to send the "q" command.  The ctrl-c command exits properly for everything I've needed, even for bad commands or non-connected cameras.  I've not run into any crashing

I've attached an example of a piece of code that will stream an RTSP stream to a file on disk.  This also contains a copy of a FFMPEG build that I've found to be pretty stable.

I'm not sure that I fully understand what you're trying to do

 

distro.zip

[Niatross]

I am trying to solve two problems, in the same application. I am open to alternatives because I am really not happy with how it is working at the moment.

I need to get live image data from 3-4 cameras to about 30 clients on a WiFi network simultaneously. Originally I planned on doing this by transmitting the JPEG binary data via UDP multicast which works well on a wired network but I was getting to many dropped fragments (and therefore dropped datagrams) over WiFi for it to be useful. I can't use TCP because there would not be enough bandwidth to do that to 30 clients. I started looking into MPEG4 streaming, and therefore FFmpeg. As part of the application I need to do some image manipulation within LabVIEW. My current dataflow is:

Cameras ---IMAQdx-----> LabVIEW -----MJPEG via TCP---- -> MPEG4 stream via UDP (FFmpeg) --------WiFi--------> Client reciever (FFmpeg) -------MJPEG via TCP------> LabView

Next week I am going to revisit trying to just do a MJPEG stream in LabView over UDP becasue what I have described above is currently quite ropey.

Second problem. It is a bit of a bodge, but I need to stream a screen capture of a particular application which is running on the server to all of the tablets. Again I need to do a little bit of manipulation before it goes to the tablets. I don't know of another way of bringing a live screen capture of an individual window into LabVIEW apart from FFmpeg (I know you can use some windows API's for screen capture  but FFmpeg still works if the application is behind other windows). Beyond that I have got the same issues with streaming the data and was planning on using FFmpeg.

I was sending the q command so that FFmpeg would close its network connections so that I can reopen them later...may not be necessary so I will test it without.

In summary, my questions are:

- My internal MJPEG stream over TCP to 127.0.0.1 works fine but I am sure there is a neater way if you know of one...I did consider using a file as the middle man but could think of a way of doing this other than writing indiviudal frames to disk as seperate files which I though was just as bad...if not worse from a CPU and disk usage point of view

- As I said previously, sometimes when I try to close the FFMPEG instance, it crashes LabView with no error. I haven't been able to identify a pattern so far. 

I am open to other suggestions as far as the overall system is concerned.

[Yesky]

Good Job

[Phil Matthews]

Hi, Do you have this project that will open in LabVIEW 2017?

Thanks

Phil

[Wiebe@CARYA]

To make this work on both 32 and 64 bit LabVIEW (I used LV23), the first parameter in SetConsoleCtrlHandler (in Kill.vi) should be a pointer sized integer:

[bjustice]

Thanks Wiebe, good catch.

Also note that this post pre-dates the release of the JKI .NET library.
As always, the JKI product is very polished.

I don't think they added the Ctrl-C command to the library yet though, but there is a request:

https://www.vipm.io/posts/d078e550-5920-460f-8c12-a9dc547cdde4/

Edited May 7 by bjustice

[Wiebe@CARYA]

The function is there twice.

It seems I also had to add the WaitForExit:

To make it stable.

Not sure if that what causes the crashes. The moment I add things, it seems stable, until a reload and then it crashes again