Jump to content

All Activity

This stream auto-updates

  1. Today
  2. clangenbahn
    clangenbahn joined the community
  3. James Arveseth
    James Arveseth joined the community
  4. hooovahh
    I am also rocking version 4.2.0b1-1 for the same reasons.
  5. Rolf Kalbermatter
    I come across them regularly here at the university. There are quite a few setups that are fairly old already and just need some modifications or updates and they work and work and work and work like a clock once setup properly. Developing for them gets harder as you have to use LabVIEW <= 2019 for that.
  6. BitPack Tools
    Okay, glad to hear there's no problem!
  7. ShaunR
    No problem. I just hadn't created a TRUE boolean so that the image is returned (default is false). I usually expect indicators to return things, except if there is an error, and not be conditional on other inputs.
  8. BitPack Tools
    BitPack Tools changed their profile photo
  9. BitPack Tools
    Good idea, thanks – I applied the change and the code is simpler now. By the way, could you share what exact problem you had with the temporary file? I still have other parts in the code that rely on it, so it would be useful to know if there are any pitfalls. The 7z license is also attached.
  10. Yesterday
  11. Hamed
    Hamed joined the community
  12. loveelysia999
    loveelysia999 joined the community
  13. Last week
  14. ShaunR
    Nice. While I was trying to figure out why I wasn't getting the image (because there is a boolean to return it ); 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: 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.
  15. styrum
    Many years ago I remember that somebody published a prank VI which would connect to another machine with LabVIEW running on it, connect to an open VI BD and move/wiggle the nodes on that BD which could indeed spook or at least puzzle a colleague working on that machine. Considering the fact that the majority of scripting properties and methods are not allowed for remote access, I would like to see again how this was done. Yes, I know that we can still run remotely any VI on the remote LabVIEW instance (if it exists there already), and that VI, as a "local", will have access to all the properties and methods, but I wonder if that prank VI was able to do what it did without planting and calling any such VIs on the remote machine. Can somebody please point me to that post or comment with that code?
  16. Mads
    That would be great. Linux RT support is all we need these days. I have not seen any VxWorks targets in ages.
  17. Rolf Kalbermatter
    Actually I do vagualy remember that there was an issue with append mode when opening a ZIP file but that is so far ago, I'm not really sure it was around 4.2 times rather than a lot earlier. I'll have to get back to the 5.0.x version and finally get the two RT Linux versions compiled. Or are you looking at old legacy RT targets here?
  18. Gribo
    Did you try calling the close method of the player before closing the reference?
  19. BitPack Tools
    https://github.com/BitPackTools/pixpack Just released PixPack 1.1.0 Removed MGI dependencies → replaced with faster native search (no external toolkit required) Dropped RC4 (Flatten/XML) encryption, only simple byte negation remains Added support for embedding/extracting external files via 7zr.exe (password required) New VIs: PP.PNG.File.Encode.vi, PP.PNG.File.Decode.vi, Write.Encrypted.7zPayload.vi, Read.Decrypt.7zPayload.vi Added a small GUI for file embedding, so it also works in built applications First versioned release: 1.1.0 README and license updated on GitHub. Note: Compatibility with earlier builds was not maintained — the changes were big enough that it made more sense to simplify and move forward.
  20. JePe
    JePe joined the community
  21. Mads
    We use 4.2.0b1-1 still (latest with Linux RT support I think) because of a requirement for RT-support, but I noticed today (surprised I have not notived earlier...) that if I try to edit anything in the produced zip files Windows will report that the archive is corrupt. I can still extract files from it with Windows, but trying to add a file e.g. will fail. Up until now we have always handled both compression and decompression with OpenG itself anyway, so the inability to modify it later in Windows was not an issue...until now. Is this a known issue with 4.2b and/or is there a way around it / fix?
  22. JKSH
    Then I'm afraid I don't know what's going on.
  23. Cédric Schmitt
    Hi all, I’m trying to display an MP4 video in a LabVIEW application using ActiveX + Windows Media Player (no other video players). On the first run, the video displays correctly. On the second run, the Media Player control shows only a black screen. Here’s what I’ve tried so far: Followed the NI tutorial: How Can I Open Video Files in LabVIEW? Used Calling a LabVIEW VI by Reference to reload the player. Searched existing topics on this forum and on LAVA, but no solution worked so far. I’ve attached the example VIs to reproduce the issue. Has anyone run into this issue with ActiveX + Windows Media Player and found a workaround (e.g., fully resetting/reloading the ActiveX control between runs)? Thanks in advance for any advice! Main VI: https://forums.ni.com/t5/image/serverpage/image-id/350275i75A0481F3CCEC3A1/image-size/medium?v=v2&px=400 Video VI: https://forums.ni.com/t5/image/serverpage/image-id/350276iDBD8FAAF967CDC56/image-size/medium?v=v2&px=400 file_example_MP4_480_1_5MG.mp4 VI_video.vi main_VI.vi
  24. robert670
    Already tried that as admin, still says I need root access.
  25. yuan11
    yuan11 joined the community
  26. ToRyN
    ToRyN joined the community
  27. ShaunR
    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
  28. JKSH
    Try logging in as admin (or use su admin on the terminal)
  29. jimmybull
    jimmybull joined the community
  30. BitPack Tools
    The password is the filename, meaning the filename carries the payload’s password. I am fully aware of the drawbacks of this approach. Users can just as easily forget the given password as they can rename the file—which is why it didn’t work for you, though you probably knew that 😃. The solution is freely modifiable, and if there is a real need, I can add an option for a custom password. 🙃
  31. robert670
    When I try to install the eGTouch touchscreen drivers on my cRIO 9042 it tells me I need root permission to do so. I have changed all the permissions for the install files to everyone and made them executable for everyone as well on my Linux PC and transferred them via an ext4 USB drive to maintain their permissions and when I try to install them on the cRIO I still get the same error that I am not root administrator. If I try to do it using sudo, it asks for a password which is not the admin password I already set, nor the lvuser password. I tried blank as well and nothing allows me root access to do it. I installed them on my Linux PC as root without issue so it is definitely a cRIO root access problem. Does anyone have any way to do this?
  32. robert670
    robert670 joined the community
  33. BitPack Tools
    I’ve added it, the license is now available on GitHub. I can’t open the VI you sent — I’m using LabVIEW 2020.
  34. ShaunR
    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. Example_1.vi
  35. BitPack Tools started following New LabVIEW tool: Embed/Extract data in PNG files
  36. BitPack Tools
    Thanks again for taking the time to review and comment! About the hex encode/decode: good point. Those two small functions originally came from the MGI Utilities, which are under the BSD-3-Clause license. I’ve copied them into the repo together with the license notice, so there is no hidden copyright issue and no need for users to install the full toolkit (as also noted on GitHub). The Error In terminal is intentionally required — that’s by design and will remain so. 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. Thanks again for helping improve this!
  37. ShaunR
    OK. Now we're cooking with gas. Some minor (and one major*) comments. Data does not survive a copy operation.* Error in (No error) shouldn't be required. Add a document that states the licence conditions that you are distributing under (e.g. MIT, BSD, Creative Commons etc) Use a Hex Encode and Decode you have written. Don't use the two MGI utilities. Make your logo smaller. 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. 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.
  38. CBY
    CBY joined the community
  39. BitPack Tools
    Hi ShaunR, Thanks a lot for checking it out and giving feedback! You were actually right — the issue came from LabVIEW’s “prepend array or string size” option in the Binary Write VI, which adds the array length (U32) at the start. That’s why the file didn’t start with a proper PNG signature. I’ve fixed it, and now the decode VI also returns the image separately, so it should work nicely even in LabVIEW. Really appreciate you taking the time to try it! Just a note: this isn’t a strictly valid PNG, since the extra data isn’t stored in chunks but appended after IEND. Still, image processing tools usually don’t mind, as they only read up to IEND.
  40. ShaunR
    It doesn't seem to produce a valid png (either as XML or "not encoded"). I've changed the extension name of the produced file (.notaping) because the web interface will not allow uploading as a png. PicPack_Embedded.notapng
  1. Load more activity
×
×
  • Create New...

Important Information

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

  I accept