Jump to content

hooovahh

Moderators
  • Posts

    3,360
  • Joined

  • Last visited

  • Days Won

    268

Posts posted by hooovahh

  1. 9 minutes ago, Neil Pate said:

    My problem with using the middle mouse button is that unless other applications use it already (like Chrome or Firefox to close tabs) 

    Is this XMouse Control thing any good?

    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.

  2. 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

    • Like 1
  3. 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)

  4. 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

  5. On 9/11/2021 at 7:42 AM, JKSH said:

    In OpenSSL 1.1.0, "libeay32" was renamed to "libcrypto"

    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?

  6. 15 hours ago, drjdpowell said:

    One question: why Network Streams?  If you are wrapping things in your own API then why not a standard TCP connection?  What are Network Streams giving you?

    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?

  7. 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.

    1298923464_Demo1.png.f32a834032e8ba2cc1062434ef551cf5.png

    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

  8. 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

    • Like 1
  9. 1 hour ago, mahgust said:

    Thanks a lot, guys! EVP is working now! md4 md5 sha1 sha224 sha256 sha384 sha512 can be calculated.

    Quite convinient and fast utility for file integrity check can be created in this way.

    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.

  10. 11 minutes ago, ShaunR said:

    As I explained. The code I used is part of ECL so commercial IP prevents me from sharing.

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

  11. 1 hour ago, ShaunR said:

    You can lead a horse to water but

    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.

    32 minutes ago, mahgust said:

    ShaunR, thanks for the idea sharing!

    Hoovah, code is attached.

    MD5_my2.png.65bdb19c6f99dc43744f5d87536a2176.png

    MD5_my2.vi 10.22 kB · 0 downloads

    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.

  12. 26 minutes ago, ShaunR said:

    Sorry. No can do. It's part of ECL but I've given you all the info to replicate it and proved it might be worth your while ;)

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

  13. 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. 

  14. 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.

  15. 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.

  16. 8 minutes ago, ShaunR said:

    Hmmmm. They have removed MD5Checksum from the palette in recent LabVIEW versions?

    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.

  17. 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

  18. 5m5813.jpg.d4b34a95536ed2a92cffaa7bc43461d7.jpg

    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.

    • Like 1
  19. 18 hours ago, Bryan said:

    I'm surprised an Admin hasn't chimed in yet to let us in on the new hotness.

    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.

  20. I'm not sure how much time you want to invest in any of these, but I looked into making my own just with the hardware we had on hand.  The stack lights we bought were cheap 24V ones, with individual wires for each light, and buzzer.  This meant you needed to use a relay of some kind to switch each light to the positive 24V to have it turn on.  Using an embedded device and some relays it can be pretty easy to setup things like blinking commands setting frequency, and watchdog functionality.  This allows you to make your own communication standard, and can be done through TCP, UDP, Websocket, Web Services, or maybe VISA.  The reason this was important to us is the devices controlling the lights might be a Linux RT target or Windows, and calling a DLL wouldn't cut it.

    The experiment didn't get too far.  I started with an Arduino Mega, and used a cheap ethernet shield and touch screen to set IP address information, along with manual relay control, and status.  It worked okay, but was over kill for most things.  It didn't have watch dog, or blink functionality and the screen I got was a terrible with very little control.  I ended up needing to hack it a bit to allow for the screen to turn off rather than be on all the time, and it used a bunch of digital lines since it was the wrong interface.  If I were to do it again I'd probably use a Raspberry Pi since LINX supports deploying LabVIEW code.

    Sorry I don't have experience with any pre-made solutions, but if it is ethernet based you can probably use wireshark to capture the communication, then replicate it in VIs.

  21. Yeah I've gone down issues like that in an attempt to make a better looking multicolumn listbox.  In my case I wanted to have custom control options in my cells.  Maybe have a Boolean cell that toggles from one color to another when clicked which is easy enough.  But I also wanted drop downs for discrete cell values, numeric controls with increment decrement, color selection with a color box, and Tab and Return key navigation.

    It turned out okay in limited usages.  But when you do things like resize a column, put it in a resizable pane, or subpanel, then lots more work was needed to ensure things looked normal.  I suspect you can get away with a cool transparent boolean, that reads the column locations and moves it there.  Just be sure and take into account the resizing nature, and hide the control when resizing or moving, then show it back once the resizing is done.

  22. Yeah I have some drafted documents about my work and integrator issues.  Still waiting a bit for the statues of limitations. 

    But the gist of it is that I worked at an integrator who sent me to a customer to do work.  I was working with them full time for a few months and they offered me a job.  There was a non-compete clause stating they couldn't hire me unless they paid my one year salary to my current employer.  Turns out I wasn't getting paid all that much and they were willing to pay the fee.  Instead I was given a raise to stay (and thereby increased the fee).  After the year was up they came back and offered me more pay since they now didn't need to pay the breach of contract fee. 

    I'd been given offers from other customers plenty of times, but this was the first place I was sent to that I could see working at.  It was sorta poaching, but totally my decision to make.  And one I didn't take without considering what I would be leaving behind.  It also wasn't a spur of the moment thing, since I had a while to think about it.

  23. 9 hours ago, mcduff said:

    Maybe not a new feature, but somewhere in the talk they mentioned a 2021 LabVIEW license would give you access to Windows, Linux, and Mac versions, no separate purchases required.

    O RLY?  I'm not a Mac or Linux desktop user, but that might give me a reason to experiment in Linux and LabVIEW if the license and software is included with our SSP.

×
×
  • Create New...

Important Information

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