Behaviour of Pipes & System Exec in Linux

[Innoworks]

Dear all,

I have tested the vi's from fblerg in order to pass commands from LabVIEW to a Linux-shell (https://decibel.ni.com/content/docs/DOC-40941). I'm using LabVIEW 2014, Ubuntu 14.04 & OpenFOAM 2.4.0.

I would like to ask if there's an example of some more complex tasks that have been accomplished by using pipes or system commands (by systemExec).

I'm trying to develop a batch-processing program to run CFD-simulations. The software to be controlled is OpenFOAM. I want to run several hundreds simulations, some in parallel, each one taking 30 minutes. Manually this is possible by giving commands in the terminal. The usual way is:

i) going to the simulation directory (this contains the parameters)

ii) running programm specific commands (e.g. blockMesh, simpleFoam, etc.)

iii) status recognition & protocolling is realized by a file (like: blockMesh >log-file.txt)

However, I used the example above and created one line like:

cd ~/; cd /home/.../OpenFOAM/.../SimSeries/Case; blockMesh >log.txt

Unfortunately this works sporadically only. However, if I replace the actual command (blockMesh >log.txt) with the command "ls" this works all the time.

I don't know where to learn about using pipes in this way.

- Can someone explain the behaviour?

- Any working examples?

- Is it possible to get error descriptions?

- All processes initiated by LabVIEW are in the system as Zombie-processes like:

3004 ?

00:00:00 sh <defunct>

...and are kept until reboot.

I appreciate any hints and suggestions.

Best regards

andreas

P.S. I also tried to pass the commands to System Exec. Similar result: sometimes it works.

[fhanke]

Hello Andreas,

I saw your questions about the pipe vi's. Nice work you did!

I was trying to look behind the pipe vi's. I did, but I got another problem! The pipe vi's are calling a library on linux which is executing all the linux commands. The problem here is, that it is impossible to see into the library. I am now in contact with the developer and hoping for a quick response. 

Every example I tried is working. I also tested it with OpenFOAM, but I used the InstallationTest Script. I used the following command to execute the Test:

cd $HOME; foamInstallationTest>log.txt

It worked fine!

Furthermore you asked for catching errors from the terminal commands. Well, errors in linux are not a usual output. For example, you get an error by typing this command "somecommand > log.txt" You will geht this error: "somecommand: command not found". As you can see with this command, it will not create this file, because there is no output. Its an error message. So, if you want to catch up errors you need an extra command to print these errors into a file.  For this use:

"somecommand 2> log.txt". With this command you can print only the errors into files. If you want to print outputs and errors into files, use: "somecommand > log.txt 2>&1".

At the end, the problem is an expected behaviour.

With the other problem I will contact the developer to geht more informations.

Wish you continued success,

Felix

[fhanke]

I got a Message from the developers! But not a good one...

The problem is already known. LabVIEW is handling this issue not very good. Unfortunately, there is not a simple way. 

If you can get the PID, then you can clean up the process with the SystemExec function. You can implement the SystemExec function into your LabVIEW project.

Wish you continued success,

Felix

[Innoworks]

Dear Felix,

thanks a lot for your testing work and also for answering some linux specific questions! I still have not managed to get the pipes & and system exec working properly. I also found some more discussion threads where other people have similar problems.

However, I have realized a rather simple workaround with which I can live:
1) By LabVIEW I write a bash file which a) includes commands (as described) and b) a job-ID (which is the time as hex-number) which is written to a other file "jobIDs".
2) The created bash file is executed by another bash file which I called "jobRunner" what just executes it every 5 seconds.
3) As soon the commands have been executed a current job-ID is present too. While my "command-process" is active, LabVIEW reads the job-ID file continuously. As soon the expected ID appears it comments the now old commands by #.

This works very well. The only disadvantage is, that the jobRunner needs to be started. The positive thing is, that I have for free a kind of job-protocol (I now consider adding some error and time lines)

Thank you again!
andreas