Jump to content

hooovahh

Moderators
  • Posts

    3,110
  • Joined

  • Last visited

  • Days Won

    220

hooovahh last won the day on September 10

hooovahh had the most liked content!

10 Followers

About hooovahh

Profile Information

  • Gender
    Male
  • Location
    Detroit MI

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2004

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hooovahh's Achievements

  1. Yup, thanks for reporting. I saw the post but didn't look close enough at it.
  2. 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.
  3. 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
  4. 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.
  5. 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
  6. 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)
  7. 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
  8. 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?
  9. 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?
  10. 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
  11. 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
  12. 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.
  13. Sorry if it wasn't clear from the original post, or my replies, but a commercial solution isn't appropriate for this.
  14. 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.
  15. I'm pretty satisfied with the solutions posted. You don't seem to be based on your responses.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.