Jump to content

ShaunR

Members
  • Posts

    4,973
  • Joined

  • Days Won

    310

Posts posted by ShaunR

  1. On 10/29/2025 at 7:57 PM, Bryan said:

    With Win 10 support being terminated, and Win 11 essentially becoming "SpyWare!_OS", many people are switching to Linux distributions.

    I only switched to Win10 3 years ago from Win 7 and that was only because I wanted encrypted SMB to my NAS.

    I'll think about desktop Linux when they fix their application distribution methods :D. I dropped my Linux LabVIEW product support for a reason->my products broke every time someone else updated their product.

    • Like 1
  2. Hi all.

    A bit of nerdy fun if you can spare some brain cycles.:)

    I've written a Steganography API (0.9.0) and will be putting it on my site under a BSD-3 licence. It currently only uses the LSB method but I may do others if there is interest.

    I've optimised it as much as I can but I expect that better people than I can improve it's performance. So. The task is to make it as fast as possible.

    There is a benchmark with some images included so we can do comparative benchmarks. I'm looking forward to some innovative improvements. The winner gets a mention in the readme under SALUTATIONS.

    If you can find the time and/or inclination then please post your times for the vanilla installation and then after any improvements as shown below.

    Times to beat so far:

    LabVIEW 2009 x64, Win10
    
    Before Modification:
    Encode: 297.9 ms
    Decode: 98.1 ms
    
    After Modification:
    Encode: 297.9 ms
    Decode: 98.1 ms

    image.png.3cdf414e970f226013e4aa9d66ed7123.png

    Oh yes. And finally. If you find any bugs, let me know and I'll fix them.

  3. Nice.

    image.png.e89a4d70da56f59f992ebf48f0be1970.png

    While I was trying to figure out why I wasn't getting the image (because there is a boolean to return it :unsure:); I noticed you used a temporary file  for the png image. There is a better option in the Web Services palette which means you can directly convert a byte string into a LV image without an intermediary file:

    image.png.bc16c3f13e81756b0365c9c12abadb71.png

     

    As you now have two different connector-panes for different modes of operation (text and file embedding), you might want to consider whether a polymorphic VI would be useful for their adapt-to-type feature.

    Finally. If you are going to distribute the 7zip binary rather than requiring the end user to download it; don't forget to heed the copyright. They want you to add the actual LGPL text rather than reference a URL.

    Quote

    Redistributions in binary form must reproduce related license information from this file.

     

  4. 13 hours ago, BitPack Tools said:

    I am fully aware of the drawbacks of this approach.

    Your customers also need to be aware of any drawbacks and caveats. If the filename is used as a key for an encryption scheme then perhaps it should be mentioned in the documentation and, additionally, what scheme you are using. I think this will be the most common reason people will seek support from you.

    I won't harp on much more about the MGI licence but just say, finally, I don't think you fully understand the issue, which could have been completely avoided.

    Just for reference, I have attached my test harness from above in LV2019.

    Example_1.vi

  5. 2 hours ago, BitPack Tools said:

    so there is no hidden copyright issue

    There is. If they create an executable they need to add the copyright to their documentation or distribution in some way as the licence is contained in the MGI VI's description.

    2 hours ago, BitPack Tools said:

    You also mentioned “Data does not survive a copy operation”. Could you clarify or give me an example? I’d like to reproduce that issue, since I haven’t encountered it myself.

    image.png.7045212c875b2ac79e4adab2ab880fd6.png

    image.png.87fb1b24b9a56326f9cd0813f6e9ae41.png

    Example_1.vi

  6. OK. Now we're cooking with gas.

    Some minor (and one major*) comments.

    1. Data does not survive a copy operation.*
    2. Error in (No error) shouldn't be required.
    3. Add a document that states the licence conditions that you are distributing under (e.g. MIT, BSD, Creative Commons etc)
    4. Use a Hex Encode and Decode you have written. Don't use the two MGI utilities.
    5. Make your logo smaller. :lol:

    With regards #4.

    You are only using two MGI utils to convert to and from hex chars. That can easily be done natively without requiring installation of a 3rd party toolkit. Using those two requires the end user add an additional copyright statement to their binary distribution that they may not be aware of (were you?). Save them (and yourself) the copyright issues.

    Quote

    * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

    If you are going to use 3rd party toolkit, require they install them as a dependency then you will not have copyright issues ... but you don't need it for this.

  7. 13 hours ago, hooovahh said:

    This feature is the VI Package Configuration (VIPC) and is free and included in the community version of VIPM.

    Just download VIPM today and activate a 30day trial to try out VIPC files.

    Pretty sure it is a pro feature. You may be able to use VIPC files in the Community version but I'm sure you can't create them without the pro version. Maybe it's changed since I last looked though.

  8. As an addendum...

    I did something very similar to you many moons ago. Maybe it will give you some ideas. Here is "Dispatcher". Should work fine for you as long as you don't select TLS. Just open the project and run the file Demo - Run ME.vi (then press Register and Subscribe buttons). It also does stuff like compression and blowfish encryption. It's a simple custom, home-grown,  protocol that I wrote to explore high-speed data streaming before the more modern protocols were available. The Dispatcher, Publishers and Subscribers can run on any machine that has network access-they don't all have to be local to each other. There is an API that can be used to implement it in applications.

    It's not really a product so not much in the way of documentation, I'm afraid.

    Dispatcher.zipimage.png.9e74a4bc63a41f00f2599a60cc1f7d2c.png

  9. 14 hours ago, Reds said:

    In theory maybe....

    But how would I get LabVIEW to create QUIC connections?

    Tough one for LabVIEW. It's a bit like RTSP - there's nothing until someone writes it.:frusty: 

    OpenSSL has QUIC support. M$ have .NET support and MsQuic.

    RabbitMQ is discussing whether they should or not. I will support it later this year (waiting for OpenSSL version 3.6).

    I have some LabVIEW prototypes that I've played with and it's damned fast with almost no overhead. It has in-built failover and multiplexed channels making it ideal for your use case. 

    Your idea of streaming directly is a good one, though. You don't really need a higher protocol unless you can identify a particular problem you need to overcome. Websockets is another that would be a good start because you would be able to have an Apache/Nginx server for routing or even send the data directly to browsers.

    Hmmm. Yes. Considering where you are now I would recommend Websockets. They are probably the easiest and get you almost all the way to where you want to be and a good start for expansion later for streaming in other more efficient and scalable protocols like QUIC. I think there are a few LabVIEW Websocket implementations to choose from so you wouldn't have to write your own.

  10. On 8/26/2025 at 2:43 PM, Matt_AM1 said:

    ShaunR,

     

    Based on what you are saying, it looks like I'd need to go down the VM route.  However, I'd like to verify I'm using the right jargon after rereading my initial message and reading your response. 

     

    When I am saying portable, I mean that I would like to be able to transfer what toolkits and what not relatively easy between PC's.  So if my PC crashes or I have to change PCs in a few years, I don't have to recreate my wheel and be super meticulous about everything.

     

    When I say isolated, I am thinking since I do dev work in 2 different versions, then those versions shouldn't be interfering with each other for common drivers, such as DAQmx.  So to me, that means that they should never be able to see each other, thus isolated.

     

    If both of these are accurate to the jargon, then I do need to go down the VM route.  However, I am unsure if what I think portable means is what it actually means 😅.

     

    Thanks,

    Matt

    Not sure what a "wheel" means in this context. I've only ever seen it in context of A.I. python scripts.

    If you are just looking at toolkits installed with the JKI Package Manager then the full version can create super packages where you can create a list of toolkits to install. you could then walk from PC to PC with that package and install them with the package manager.

  11. Hey Person of Fancy

    If you want device drivers, DAQ, vision toolkit or 3rd party driver support then VM is the way to go. All versions of LabVIEW work fine (with caveats) in Virtual Box and VMware - just read up on NI's licencing requirements for VM's. This will be GB's of data each save and VM's run like slugs compared to your dev machine. Also the computer hardware will not be representative of the final target you will deploy to. So beware- here be dragons!

    When it comes to LabVIEW, I also have USB sticks with customer specific versions so that I can go on-site and seamlessly integrate into their teams. These are only applicable if device drivers et. al. are not a concern (e.g. UX, TCP, GPIB, Web Applications and stuff like that). Some want me to keep the USB while others want to keep the USB stick with IT - in the latter case, source control is their problem and for the former I just check in the entire USB stick.

    if you don't use a VM and have multiple LV versions, there are 2 issues you need to be aware of

    1. You can only have one NI-DAQ version across all LabVIEW versions (this is the main reason why you need VMs but there are others). If multiple versions are needed in different LabvIEW versions then VM's is the only way.

    2. Recompiling in a later version is a huge risk because back-saving is, anecdotally, about 90% reliable and can easily fail in convoluted cases. The best defence is to adopt a workflow that mitigates the chance and rely on source control when that fails or vice versa. Projects are relative paths so as long as you include all code under your project directory (and don't scatter it around different drives and non-hierarchical directories) you should avoid this most of the time. For those times you don't, revert from source control or back-save. Keep your project code separate from vi.lib!

     

  12. 1 hour ago, noir_desir said:

    It's possible to system linux modify the structure? 

    Unlikely. You clearly have a lot more decoding layers than you have shown so far (is that a DrJPowell messenger vi rather than a network stream vi?). The probability is that your variant isn't what you think it is or your middle layers are modifying the variant (casting to strings and including a length, for example).

    Using the send in your example, write the example for receiver that I showed previously and test it can be received and decoded.

×
×
  • Create New...

Important Information

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