64-bit version of lv_proc.dll?

[dadreamer]

Hi, Kaero!

I just tried your LV Process library and it works great! But I'd like to ask... Will lv_proc.dll be released for 64-bit LabVIEW or not? Personally I prefer 64-bit instead of 32-bit, because I can operate all the memory for my needs etc. And the second question is - why all your CLFNs are set to run in UI thread mode? Does that mean that the library is not thread-safe? I haven't take a look into the DLL sources, sorry.

Thanks for keeping up your work on this.

[mmccullo]

I have the same issue. Tried to use it in LabVIEW NXG 2.0 and 3.0 beta and I have problems with the fact that it is not a 64-bit DLL (dependency errors in NXG). I am presently working with the DLL source to see what I need to do to bring it to 64-bit.

[bsbinu]

Hi Any update on this thread? I am also looking for a 64bit version for lv_proc.dll

[KaeroDot]

Hi guys, sorry for the looong response time. Too much to do.

I thought it is possible to link 32 bit binary in 64 bit system? Concerning the UI thread mode - it worked, so my colleague didn't cared if this setting needs to be changed or not. Personally we do not use (yet) LabVIEW NXG. I believe you just need to recompile the source code of the library for 64 bit, did someone tried it? Anyway I asked my colleague to compile lv_proc.dll also for 64 bit.

[mmccullo]

I tried a simple recompile but get numerous warnings about int32 being auto converted to int64. I am also unsure as to whether some of the method calls must have some args changed from int32 to int64 for 64-bit application. I think I just tried leaving as is with a 64-bit recompile and converting all int32 to int64 -- neither seemed to work (might have made some other mistake).

I am able to use the code as is to work with 32-bit LabVIEW, even saving the VI's back to LV version 8.2.1. I did make a change from SW_HIDE to SW_SHOW in the DLL source for the Window state because I have a scriptable GUI app that responds to stdin/stdout comm while also allowing GUI interaction in Windows.

I also had some contact with NI tech support and them seem completely uninterested in an "out of the box" persistent pipes implementation in LV for Windows.

[matthewnevels]

Hello All - First I want to say a huge Thank you to KaeroDot 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.

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 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 have attached a .zip that includes the source file that I changed and the compiled x64 dll that is working for me:

lv_process x64.zip 2019-04-22 Edit: use the following - it is compiled as 'Release' the above was compiled as 'Debug' and requires the development environment installed in order to use: lv_process.x64.zip I will also post to the NI Forums thread on this topic: https://forums.ni.com/t5/Community-Documents/LV-Process-Windows-pipes-LabVIEW/ta-p/3497836

Here is a VI Package Manager package that updates Hooovahh's edit with this .dll and containing a conditional disable structure in each VI that selects the correct .dll based on the bitness of LabVIEW that you are running. This allows you to install and run the same package in LabVIEW 32bit and LabVIEW 64bit. mssm_lib_lv_process-0.7.1.2.vip.zip

The only Issue I've had is if you use the option to show the console and you click the 'X' to close the console window while your program is still running it will kill LabVIEW at the same time! This doesn't bother me because I will not be showing the console in any of my applications. It's nice to use while debugging though.

[ileGITimo]

Using the mssm_lib_lv_process-0.7.1.2.vip.zip in the previous comment, several GOLPI VIs either seem to be broken or I didn't get the proper version. The command(cmd0) and working directory inputs of LV Process' Creat Process.vi are swapped and the type for directory is now a path.

[cti-mnevels]

@ileGITimo I just used VI Package Manager to remove my copy, then downloaded the version from the link in my post above and installed using VI Package Manager. I was then able to open the demo apps and verify that all is working. I'm using LabVIEW 2020 x 64. I verified that the command input is a string and the working directory input is a path. As for troubleshooting your installation I'd start with using VI Package manager to uninstall the version you have. Verify the MssM folder has been removed from your vi.lib folder. Then re-download and re-install.

[ileGITimo]

@cti-mnevels Running LV 2018 64 bits (also have 18/32 15/64 and 15/32) installed. Using VIPM 18 uninstalled LV process and GOLPI, vi.lib/MssM was gone. Installed LV Process 0.7.1.2 from your link (as matthewnevels) and GOLPI 0.7.0.1, unselecting the old dependency this one wanted. Demos under LV Process work. Demos under and some GOLPI VIs are broken.

[matthewnevels]

@ileGITimo I believe that I have found the issue and it looks like I caused it. I have never used the GOLPI side of this project, only the LV Process side. It's been a good while since I built the 64 bit dll. I just downloaded the GOLPI code and after looking through it I do see what you're seeing. It appears that when I updated the LV Process library I rearranged the terminals on the Create Process.vi. The newer library does not need to have the path to the lvprocess.dll as an input and so I removed that. I then apparently swapped the order of the terminals so command is the first and working directory is the second. It also appears that I changed working directory to a path. Looking back, I suspect that in my inexperience I changed those not giving any thought to the fact that LV Process might be a dependency of another project (...GOLPI) and so my changes now require changes to any tool that was using a previous version.

It will be trivial to fix the GOLPI code to use the newer LV Process package. Just pass the working directory as a path instead of a string and rewire the command string to the correct terminal. It should work after that. I cannot test because I don't have any of the Matlab tools or anything else GOLPI might be dependent on. I don't manage this repository and haven't heard anything from @KaeroDot so if I made these changes I don't know that I'd be able to submit those anyway.

[ileGITimo]

@matthewnevels Yes, it is trivial to fix GOLPI, I had already did that and got the GOLPI demos to run, maybe I'll open an issue, not sure I want to do a pull request when the changes are in binary VIs. Also found a bug in GOLPI where the executable in the command line to start Octave needs to be quoted, as it contains a space. I have Matlab installed, but you don't need that, just don't enable Matlab mode. You'll need Octave.

[matthewnevels]

@ileGITimo Glad to hear you've got it working. It's good that this is now at least documented in the discussion so others that come across this have a resource to make things work.

[ileGITimo]

@matthewnevels Yes, it is now officially documented :-) And fixes to GOLPI to use the LV Process version you posted in this thread won't make sense until @KaeroDot updates to use that version.