hooovahh

VMs to the rescue! Well sorta. I'll create a VM set up the OS the what I want, then take a snapshot. Then copy over an installer with none of those things selected and install it. Then run all the features of my program I can think of. If it is broken, or things seem missing I go back and try to make a new installer with something checked that I think it needs based on what didn't work. The VM allows me to roll back to a snapshot of when nothing was installed quickly. But yeah for the most part, this only reduces the run-time engine size a little, and while I don't like unnecessary services, spending the time to reduce them doesn't feel worth it to me. In the past I'd spend time reducing it and making it as small as possible. And then I'd use some feature of something like the Math Kernel, make a new build, and now things aren't working and I need to go back and update the installer. When previously I'd just not worry about it and include everything.

Is it ever conceivable that there will be more than two Queues to monitor? If so then the last one would scale up better. That being said it isn't the one I'd find myself using, just because the other two are much more readable. I'd probably go with the first one. Swap values is pretty handy when you actually need to swap two values. Here you aren't really using one of the values. From a memory or speed perspective I bet you can't measure the small amount of difference (if any) that is taking place.

Yup, thanks for reporting. I saw the post but didn't look close enough at it.

I've seen this a few times, and you probably already realize the simple solution is to just Select All >> Copy >> New VI >> Paste. This loses the VI description and icon which can be manually added. Still I agree it is weird that some VIs are harder to back save for some reason.

Super cool! I've often used a very hacky solution for this usually involving lots of extra .Net and PictureBox functions, then saving to memory buffers, that I'd then said to LabVIEW to get pushed to a 2D Picture control. This makes this much, much easier. And I was surprised it handled multiple transparent images on top of each other well. I'd love to see this on the palette maybe even along with some other PNG related functions like: Add LV Image to PNG Data.vi and PNG Data to LV Image.vi Both of these found under C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\wsapi\VIs\ Add Create Mask By Alpha.vi Found here but might not be as important if Draw Flattened Blended gets added C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\picture\picture.llb\Create Mask By Alpha.vi Expose the compression input to the LV Image to PNG Data

The config I attached already takes care of this. You can make several profiles and the one I attached only gets applied if "LabVIEW.exe" is the active program. So when you are using something other than LabVIEW, the mouse acts like it normally does. I tried other methods of detecting when LabVIEW is active, and it was less reliable. I tried doing something like attaching to some system core process LabVIEW uses. One odd side effect I noticed, is if you open a help menu from within LabVIEW, then press the back button on the mouse, it doesn't work like it should. Still I'm not using back in the help documentation much. It does have a capture for tilting the mouse wheel and it might be possible to have it pan using that too.

Oh this is a great idea and something I was able to do pretty quickly in XMouse Control. So previously I had mine configured so that the middle click would invoke <CTRL><Space> so that I could middle click and bring up the quick drop. I also have it so that if you press the back and forward buttons on your mouse, it will cycle through the cases of an event structure, or case structure. But this was a pretty easy thing to change the middle mouse to perform a pan instead. Attached is my config but it personally won't be helpful for me since I am a non-auto tool guy, and it requires auto-tool to be on. Just go download the X Mouse utility and use this config which should only get enabled when LabVIEW.exe is the active application. And if you are interested in the Middle click invoking QuickDrop go checkout the config I posted on the dark side. EDIT: Oh another thing I noticed is this only works if you use the middle click when on blank space. If you try to pan on an object it will copy it. LabVIEW Pan and Case Turn.xmbcs

Right well this set of code wraps Network Streams, adding synchronous two way communication, and uses VIMs to allow for the Request and Response data types to be typed and more easily used. It also adds some periodic reconnect, and connection status feature that I find helpful. Maybe XNodes would be better but VIMs are just so much easier to make, especially for a first release. It is true that Network Streams are themselves wrappers around TCP technology. And for those that don't know the intricacies of TCP this is a pretty easy way to setup two way communication between two pieces of LabVIEW code running on the same machine, on a different machine, or on different targets, just by specifying a Host and Client identifier, and specifying the Client IP address (if on a remote system). I'm certain that any example I give for Network Streams, you could make better with TCP. (EDIT: This comment wasn't meant to be sarcastic in anyway. I haven't done any real TCP development and am sure you are more familiar with it than me)

Okay attached is an updated version that I think supports the changes I made. It reads the registry in 32 or 64 bit LabVIEW finding the path to the shared installation location. In Linux it tries both the libeay32.so and libcrypto.so. In both cases it keeps the found path in a feedback node for later calls. I also added outputs instead of void for calls, but am now realizing this version doesn't do anything with them yet. MD5_my9.vi

Thanks for the info. Looks like a wildcard can't be used to select the new binary based on the naming. I could add code to say if we are on Linux, and the first call to "OpenSSL_add_all_digests" returns an error 7 (file not found) when using the path "libeay32.so" to the binary, then to try one more time using the path of "libcrypto.so". I mention this method because I don't want to specify the full path, but the Check If File or Folder Exists doesn't search for a file in global path locations. Not sure if there is a more elegant solution. Speaking of hard coded paths the Windows method is obviously not ideal at the moment too since it is a hard codded full path. What would be the best solution here? Reading registry information on first call?

Because this whole endeavor started as a Network Streams user group presentation. In making Network Streams examples I realized it could be simplified. Then while creating demos I thought it could be used for this. The purpose of this post is really to discuss the Network Streams examples, one of which is this 64-bit 32-bit DLL calling business. I just figured that was the topic most interesting to others. It certainly could be just TCP stuff instead. I didn't see any actual examples of 64-bit LabVIEW calling a 32-bit DLL. But I saw on the forums lots of people asking for such a thing for a variety of reasons. If anyone has any examples of this I missed please let me know. So this might go into a larger topic. But LabVIEW is sorta backwards when it comes to 32 versus 64 bit. If I go to download Google Chrome what version is recommended? But when it comes to LabVIEW 32-bit is still recommended. However I get the feeling NI is going to push 64-bit more, with the recent releases adding more 64-bit tools. I'd like to make the plunge to 64-bit LabVIEW. But for actual application stuff I occasionally use 32-bit DLLs as mentioned in the post. One case for me is a security DLL we are provided. But lots of random hardware drivers are just DLL wrappers. And if that manufacturer doesn't have 64 bit support or went away, what options are there in 64-bit LabVIEW?

Hey all. So I'm planning on giving a Network Streams presentation to our local user group and was working on some examples and code, and figured I could make it into a full blown package at some point to help simplify the Client Host connection having automated retries, connection status, and using VIMs have the ability to specify the Request and Response data as a type def. The code still needs some work, but is in a decent place as far as the examples go, but is missing documentation and icons. It requires LabVIEW 2020 or newer, and the last example requires both 64 and 32 bit versions of LabVIEW. The basic examples all seem to work with the one I'm most interested in feedback on being the 64 Bit DLL calling code, but first the others. Example 1 Client Host Together This is the simplest demo showing the Client and Host in a single VI. All that is needed is to specify what the Client and Host identification is. Here it is hard coded as "Client Loop" and "Host Loop". With it a Host can send a request for some work, and get a response. The Client will sit in a loop and get a user event for the work, then send the response. Example 2 Client Host Together The next progression is a Client and Host that are separated in different instances or contexts. The code is practically the same but each loop now has its own project and can be built into separate EXEs. Here the IP address is localhost so both Client and Host need to be on the same computer. Example 3 Remote Client Here is where it starts getting fun. The Host is ran on Windows (EXE or development) and then the Client can also be either ran from a separate EXE or development. This Client can be another Windows PC on the same network or an RT target that has Network Streams installed through MAX. The example project has an RT target. And the Host has an IP address for finding the Client. Example 4 64 Bit DLL Calling And this brings me to the real fun. So a 64 Bit executable can't call a 32-bit DLL directly. It either needs some kind of wrapper, or another translation layer. Since Network Streams supports talking between different versions of LabVIEW it also supports sending data to and from different bitness of LabVIEW too. So what you can do is open the "Remote Client Test - Host Main.vi" under Example 4 in LabVIEW 64-bit. Then run the EXE named "Remote Client.exe" which is a 32 bit EXE. Instead of running this EXE you can also open and run "Remote Client Test - Client Main" in the 32-bit version of LabVIEW. If both the Client and Host are running, and both show a Connected status on the front. Then what you should be able to do is put a file in the Path control, then click "Get MD5 Method 1". This will send the path of the file from that control (just the path not the actual data of the file) over a Network Stream to the Client, and tell it to run a series of Call Library Nodes to get the MD5 of the file. You can also try clicking Method 2 which will instead of doing it in one call, it will read the file in chunk on the 64-bit side, then send that data over Network Streams to the 32-bit side, where the DLL calls are made. I don't like that to make this work you basically need to duplicate your work. On the 32-bit side you need to code talking to the DLL, and get the request data from the Host converting it to what you want, then getting the result and sending it back to the Host as the response. Then on the Host side you need to write a subVI that takes inputs, flattens them down into sending the request, getting the response and unflattening. At the moment I used Variant attributes because I wasn't being creative. I'd love a more streamlined method that could work by specifying DLL inputs and data types. Or just make it easier for developers, possibly with scripting? XNodes replacing Call Library Nodes? Or using them as a template? Thoughts? Also another issue is needing to run a separate EXE. I'd love to be able to embed in the 64-bit VIs the needed 32-bit EXEs, and then have a daemon for starting up and stopping that EXE. This will mean the first call to it will take several extra seconds, while the 32-bit EXE is started up in the runtime engine and gets ready to get a Network Stream request. In a real application this could be done on start easily. MD5 Details No you shouldn't use this method to actually get the MD5 of a file from a 64-bit version of LabVIEW. There are better alternatives. But what I wanted was an example of getting a 32-bit binary to do some work, that a 64-bit version of LabVIEW could have it do. By the way this code is lifted from a discussion here. Actual Usage? So as for the actual usage of a thing like this. I have a few pieces of hardware that talk over a 32-bit DLL and don't have a way to talk to them once I go to LabVIEW 64-bit. They aren't critical hardware, and are old so maybe I should just let it go. But part of me wants to update these APIs so that all versions and types of LabVIEW can talk to them. I also have a couple of customer DLLs that are 32-bit and are just black boxes that I need to use for security reasons. Performance? Untested, but probably not great depending on the amount of data that gets sent back and forth. Alternatives? If anyone knows of good examples of having a 64-bit version of LabVIEW call a 32-bit DLL I'd be interested. Regardless the Network Streams portion of this code will likely be published at some point after the user group presentation. Thanks. 1069999985_NetworkStreamsTrialand64DLLCalling.zip

Here is my minor contribution. Following a thread on the NI forums it seems Open SSL support when installed (through MAX as an optional software package) the compatible binary is libeay32.so. So I updated the code to remove the Get/Set file positions, and specify the file path using a conditional disable structure. I tested it this morning on my RT VM and it worked great. The same 1.4GB file took 20s using native G and only 2.2s using the Open SSL version. MD5_my8.vi

Sweet. My test file was about 4.5s via command line and was 2.2s using your code. I'm pretty sure this is just copied over from the NI example, but we can get rid of all the Get and Set file positions. Not sure why NI put them there in the first place. Also is this NIlibeay binary available on other RT targets? I looked at the SSL functions used by Webdav, and the HTTP functions, and they call other NI binaries, the ni_webdavLVClient and ni_httpClient files that likely have a .so file or .dll based on target selection. I see Pharlap versions of this library but not any others.

Sorry if it wasn't clear from the original post, or my replies, but a commercial solution isn't appropriate for this.

You most certainly can. I asked for you to share your improvement so everyone can benefit, you just seemed interested in talking about it but not showing it. Unfortunately I get "Not Enough Memory to complete this operation" error when I try it on my 1GB+ file. I suspect the other functions in that call library node are needed like Init, Update, and Final.

I'm pretty satisfied with the solutions posted. You don't seem to be based on your responses.

Very neat, glad you found an improvement. But it seems like you forgot to attach the code. Are you still making improvements?

My quick test shows it did an MD5 in about 3 seconds, when the other command line was 4. However if your purpose is just to ensure a file integrity, MD5 might be over kill. I found a CRC32 posted here, which is in G so it works on all platforms LabVIEW does, doesn't require an external binary, and is also done in about 4 seconds. If you really need MD5, and you need it to be fast, but don't care that it is Windows only, you can use one of these. But if you just want a fast file compare and don't care about the format, I'd go with something simpler like the CRC32. But also test it with the typical file sizes you'll be seeing. On smaller files the difference might be a rounding error.

Well this code has been here for 12 years ready to be improved, I just went with the fastest easiest method to use. If you have improvements the community would love them. I just ran a quick test on a 1.4GB file on a SATA SSD. NI's method was 21.4s. A pipelined version using queues was 21.1s, the command line version was 4.2s. I copied it to my NVME drive to compare, and the numbers were very similar indicating the slow down likely isn't file IO. When something takes 21s a progress bar is probably needed, when it takes a couple of seconds it might be nice, but but it is less of a concern. I likely will just make a wrapper, and if on Linux use the G code, and on Windows call the embedded binary. EDIT: Also I tried the new file integrity functions and they all performed pretty bad. The fastest I found was 30s on the same file. A checksum was about half a second.

Yup totally agree. Taking a look at the source again I wonder if we could improve the speed by pipelining the process so processing and reading of file chucks happens in parallel. Still I doubt the native G implementation could make up so much ground when the command line version is so much faster.

They did remove it from the palette and I complained. If you find the VI it has text in it saying it has been superseded with the newer file integrity stuff. Which is half true. There are new file integrity stuff but it doesn't support MD5, and NI has said it was due to security concerns.

Hey no worries. So here is the file that was on my website. It hasn't been up since I moved, I really should try to fix that. Still I wouldn't mind revisiting this topic to see what else can be done. In the past I really wanted an MD5 just to verify a file is copied properly and for that I do a faster checksum. MyMD5File.zip

Also I'd love for proper unicode and long path support for file paths. I have hit the too long file path when building RT software. LabVIEW copies parts of the source to the destination location temporarily, and duplicates the hierarchy. This might mean that your usable practical path, is only have half of your 260-ish characters. The easy fix I've been doing is setting my build location to some place like C:\RT Build and then having a post build VI take care of the clean up and renaming.

I might be wrong but I think there is only one Admin left. As a Mod I don't have control or visibility on this. I was surprised as everyone else. But at the same time I just assumed this was a relatively simple update on the board that came with a new feature. It probably is a good idea to just keep the place somewhat up to date, rather than waiting several years and then have a much more difficult update process.