LV Process - Windows pipes LabVIEW

[kaero]

Yet another implementation of pipes in LabVIEW for Windows operating system. (OpenG implementation seems to be abandoned).

VIs call lv_process.dll to start a process, send and receive data through stdin and stdout, closes process.

Pipe is in fact cluster containing handlers and setting. User can change the cluster values as required (be careful).

All traffic can be logged if debug mode is started. Debug console can be shown on the background.

Main purpose of use is GOLPI (Gnu Octave to LabVIEW Pipes Interface), see other my documents at NI Developer Community.

Project is open source code. You can get latest version and source code at GitHub: https://github.com/KaeroDot/GOLPI

Authors: myself and my collegue Stanislav Mašláň.

Latest version 0.6.0.1, and the 0.6.0.1 Hooovahh Edit which is in LabVIEW 2015

[D.Barr]

Just used the pipe VIs to automate Plink command calls to
create an SSH connection to a Linux box. So far everything is working great.
Thanks for amazing useful vis!

[SebastianM]

Hi kaero

Thumbs up for this cool project! (meaning the whole idea of GOLPI)

The LV process package seems to be just what I am currently looking for. I want LV to drive a console application through the stdin and stdout streams. NetCat to be specific.

Unfortunately, I could not get your VIs into my LV.
LV2012 complains that the lib has a newer version. I can still select the VIs inside the lib, but they won't appear on the block diagram.

LV2014 (just installed) says it can't open VIs from a lib made with an older version, with pretty much the same effect.
So, I assume the lib was made with LV2013, correct?

Actually, I could just as well make my own wrapper VIs for your DLL functions. I would just need a brief description of those functions and their parameter lists. Is something like that available?

Cheers!
Seb

[kaero]

Hi, good to know you like it.

Please go to my webpage, dowload the source code, and take a look at all files inside. You will see VIs developed in LV2013, and you can recompile it to your LV version if you like. By making your own wrapper you would just duplicate work already done.

Concerning the documentation of the DLL, take a look into the source code, there is description of functions in the source itself lv_proc_main.cpp.

[SebastianM]

Hi kaero

Thanks for the quick response.

Actually, I had a look into your sources, and just tried to access the DLL functions directly from LV. I got to the point where proc_create returns with a CANT_CREATE_PROC error. Perhaps I am not passing the parameters in the correct way.

You are right, making new wrappers would be duplicate work. But I want to avoid yet another new LV installation. Could you perhaps provide a copy of your lib saved in the 2012 format?

Best regards!

Seb

[kaero]

Unfortunately I do not have a 2012 installation of LV, I have only 2013.

I do not understood the problem with LV2014 - can you open project file GOLPIsource.zip\LV Process\LV Process.proj, in project window select Build Specifications, Packed library and run compilation? Or save the project or VIs of the library in LV2012 version (I have no idea if this is possible?).

Anyway to create a process, you need to do this (content of GOLPIsource.zip\LV Process\Create Process.vi )

[SebastianM]

Hi kaero

Frankly, I did not understand the LV14 problem either. For some reason it did not like the LV13 library.

Thanks for pointing me once more to the GOLPI package. At first I was so focused on the C source files that I totally overlooked the VIs that are provided there outside the libraries. These I could load in LV14. The Demo.vi works fine, so I can start experimenting with my own stuff.

For the records: you do know about the option "Save for Previous Version..." (in the File menu)? This allows to save the VI at hand (and those it depends on) in any of the previous formats. That's what I meant earlier.

Many thanks, once again!

Seb

[viScience]

Hi Kaero - I am using your process vi's in LV 2014 and it works well for opening up a process and sending strings.  The problem I am having is that once I start the process I run an exe that is a console app.  I can send strings into the process and they are received by the console app that is running.  The output of the console app is not fully appearing in the process window, It seems like it is getting truncated.  Upon the next output of the console app the truncated text appears with the first part of the subsequent response.  Do you have any idea what could be causing this problem?

[smaslan]

If it truncates part of the console stdout then it might be internal DLL overflow. How much data your console returns at once? As far as I remember the WinAPI for pipe creation has a parameter that specifies pipe buffer size. I left that at auto. So it might be too small for your console. LV_process reads entire content that is in the pipe buffer and returns. The console then sends next part and you have to read it again. So try insert some delay between write and read and if it won't help you'll have to do it in following way.

Solution might be to use one of the additional functions from the DLL. proc_command(...). This function sends command to console stdin, and then reads console stdout several times until the delay between subsequent returns of the console exeeds certain time. Unfortunately this function is not implemented as a VI in the library sou you'll have to download source distribution, look into the DLL source code for the function usage and then implement it as a VI. Or you can download GOLPI source distribution and use VI called "read until settle" or something like that. That should do the same thing except the repeated readouts are implemented in VI instead of DLL itself.

[Hatefk]

Hello,

I have LV 2012 SP1 and am not able to open any of the files in the .vip package.

[kaero]

Hi Hatefk,

I tested now the lv_process_lvlib-0.5.2.1.vip file in VIPM 2014 and it seems to be ok. How did you tried to open files in package? Anyway you can always download whole project in zip file: LV Process 0.5.2.1.zip

[Hatefk]

Hello Kaero and thanks for the quick response.

Im using LV 2012, it seems that my version is too old.

[Hooovahh]

Wow fantastic tool, not sure how it eluded me all this time.  I've never used the OpenG pipes, but having something that is more maintained is important.  That being said I did find some issues with the toolkit, talking about just the pipes software.  Many controls weren't on the root of the block diagram.  This is a CLD requirement and is because performance can be effected.  I also am not sure why you are specifying the DLL by a path.  If you specify the DLL in the call library node LabVIEW knows it is a dependency and will always include it in applications and know it should be loaded.  If you specify it by a path you also need to make sure you include it in the application builder manually and find it based on the path properly.  Your method for finding this DLL path was flawed too.  You could drop the demo from the palette meaning it wasn't in a project, and as a result the path wouldn't be correct.  It would only work properly if you opened the included project.  Icons needed to be updated, the palettes should be arranged better, and I saw several VIs that could have default values set, and then have their terminals be optional for easier use by the developer using this toolkit.  Also if you are going to use custom error codes an error code text file should probably be made and included in the package.  I've made many of these changes and rolled them into the Hooovahh Edit version that I'm putting in this document (since I can't attach to this comment).  I didn't update the palette (because it isn't a package) and I didn't create the custom error codes text file, but I think all the other changes I mentioned I did.

Also I think it would be interesting if in the future a demo could be included that does something like query the pipe periodically.  The first thing that comes to mind is something like a VI that uses Robocopy and duplicates a folder to another location, and then periodically reads the progress of the copy.

One other thing, is there a 32 versus 64 bit issue here?  I've been using this in LabVIEW 32-bit inside Windows 7 x64.  I assume this only works in 32 bit LabVIEW, but is a 64 bit version of the DLL possible?  I don't use 64 bit LabVIEW but others may.  A Conditional Disable Diagram structure can choose to use the 32 or 64 bit versions of the DLL (assuming they are named differently)

[Hooovahh]

Oh and hey a new question.  I'm looking to send commands to a session using stdin.  For instance if you are performing an operation in a command prompt the CTLR+C or ^C will abort whatever is going on.  Do you think it is possible to send this type of abort command and if so how?  Thanks.

[binu.balakrishnan]

Hi, Is it possible to establish a live python interface through the pipe the same way I can work on the Windows command menu? looks like application goes in to error mode once I run “python.exe”. Please see the normal windows command version and what I get back while I run LabVIEW. Is there any limitation in running an exe that is a console app like “Python.exe”?

--------------------------------------------------------------------------

Windows Cmd shell response ...

C:\>python.exe
Python 2.7.11 |Anaconda 4.0.0 (64-bit)| (default, Feb 16 2016, 09:58:36) [MSC v.
1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>>

-------------------------------------------------------------

LV Process shell response (shell hanging)

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

c:\>python.exe
python.exe

[MNevels]

Hello All - First I want to say a huge Thank you to Kaero for creating and releasing this tool! I still have a hard time understanding why this functionality isn't built into LabVIEW for Windows yet - it is tremendously useful for automating proprietary 3rd party programs that do not provide api access. I'm sure there must be some technical hurdle that I'm unaware of.

Second - let me preface this release with the statement that I do not know windows programming. I downloaded Visual Studio Code Community 2017, cloned GOLPI commit a41de39 and attempted to build - using StackExchange and Google to assist me with determining what I needed to change to get it to build. There were some things I had to change regarding Unicode and integer types, but I finally got it to build. I have done limited testing but all appears to be working for my needs, I have not had any issues at all - that is not to say that there aren't any. I am not aware of the implications of the changes I made to the code to get it to compile, I just know that it appears to be working for me on LabVIEW 2018 x64.

I would certainly feel more comfortable if this had been built by someone who knows windows programming - I leave no guarantees as to what this will do for your system. I don't know git well enough to know what I'd need to do to submit this change properly into the repository. I will have to leave that for the author to do as their time and resources allow.

I don't see how to attach files here, but I have attached a .zip that includes the source file that I changed and the compiled x64 dll that is working for me to the Github thread on this topic:
https://github.com/KaeroDot/GOLPI/issues/4

[Raydur]

Quote from Hooovahh: "Also I think it would be interesting if in the future a demo could be included that does something like query the pipe periodically. The first thing that comes to mind is something like a VI that uses Robocopy and duplicates a folder to another location, and then periodically reads the progress of the copy." I'd like to add a vote to this comment/request - Can this be done and added to this project? For those of use who are not the most experienced with this it would really help bridge the knowledge gap to be able to use it!