Jump to content

Antoine Chalons

Members
  • Content Count

    710
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by Antoine Chalons


  1. Quote

    So I have been trying to think of a way to attempt to allocate a very large string with a graceful way to fail if there is not enough memory.   Has anyone else found a way to do this?

    I have not.

    Last I faced a similar case a few years ago (on a 32-bit Windows), after some discussion with the users we agreed to check the file size before loading it and if it was larger than 400Mb the soft would reject the load request with a nice message telling the user to use another soft that would split the large file in several 400Mb files.


  2. My advice is to "look into CXP", I never got round to trying the bitflow HW + driver which they claim is fully compatible with LabVIEW, CXP seems to be the future of industrial high res / high speed vision. So if you're looking to build a vision system for the next 10 years, I think you should test out bitflow's CXP option.

    I'm a bit disappointed with NI's "wait n see" approach with CXP, last I asked the answer was "we don't think the ROI is big enough". Which is a fair point but leaves NI Vision with very limited options.

    CXP open a lot of options in term of cameras.

    Good luck to you, and - again - if you do test bitflow cxp framegrabber in LabVIEW i'd love to hear how it works.


  3. 5 minutes ago, Rolf Kalbermatter said:

    The lvzip.so file on normal Linux should generally remain in the root folder of the lvzip package for source code distributions. That should make sure that the application builder will include the shared library into the application build in a support folder (usually called data) on all platforms where that matters. Doesn't that work for you? I don't really have experience with application builds on Linux. I only use that platform for testing in the LabVIEW IDE and only really have two LabVIEW versions available for that.

    I knew it would be the case on Windows and I was/am not sure about Linux because I have not compiled an application on Linux yet, it will be my first so I'll be careful with this.

    Thanks again for you support.


  4. Ha, today a new customer (a university) is requiring us to deploy our software on a Linux computer (not NI Linux RT).

    So we have a Linux machine on which we have LabVIEW and VIPM, we compile our application on this computer and then we need to deploy to another Linux computer that doesn't have either LabVIEW nor VIPM installed.

    If we simply manually place the so files from File Group 6 into a folder - which folder by the way? -, is it going to be enough to make it work?

    Cheers!


  5. Perfect, it's quite easy to do and it works just fine for me.

     

    My use case is that I want to update my rtexe on an NI Linux RT target, previous version didn't use OpenG Zip, new version does.

    And to update the target I have a computer that only has NI Max.

    Is there a way to build my rtexe from LabVIEW in such a way that it includes the dependencies of the OpenG Zip package to make the deployement easier?

     


  6. On 9/4/2019 at 10:23 AM, Rolf Kalbermatter said:

    The realtime support will only get extracted when installing into LabVIEW for Windows 32-bit and through a seperate exe file that is invoked and will prompt for an administrative elevation of this installer. You then have to go into NI Max and into the Software part of your target and select to install additional components. In the list should be an OpenG ZIP Tools version 4.2.0 package visible.

    If I understand well it means, LabVIEW 32-bit is needed on the computer to be able to deploy the package to a RT target, right?

    What would be the way to deploy this package to a Linux RT Target from a Windows computer that has NI Max but not LabVIEW?

    Is it possible to extract the EXE you mention from the package, run it and then deploy from MAX?


  7. 26 minutes ago, Neil Pate said:

    So out of curiosity, how does everyone else handle their name generation? Multiple cameras with multiple image processing steps each needing temporary storage. I usually try and programitically generate the name but now that I think about this thread there must be a better way that I don't know about. 

    I have a "rule" something quite basic like "VisionSystemRef_CameraName_BufferType_Index"

    For the buffer type I have a typedef with a few options :

    - "Acq" for acquisition only buffer, I never do any processing on these, they are used only to store an image that has just been acquired from a camera

    - "Save" buffers reserved to store images that will be saved to disk

    - "Proc" for processing

    - "Disp" buffers reserved for images to be displayed on the UI

    So I use the "image copy" VI a lot do to transfer image data from a buffer to another

    • Like 1

  8. 6 minutes ago, Sam2004mai said:

    Why this website suffers from broken links i cannot download any of post linked examples. can anybody help post again the MCL example with multi Glyph.

    I can download the files from this thread just fine.

    I'll try sending you a private message with the VI


  9. 3 hours ago, Neil Pate said:

    Whatever you do, don't be tempted to access them via their index position in the Decorations array, the order frequently changes and will cause very subtle coloring bugs in your code! 

    Oh yes, I did burn my fingers with that one, I believe you get then sorted on their last modification date or something alike.

     

    Edit :

    oh, and by the way : https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Explicit-Decoration-References-to-LabVIEW/idi-p/975701

×
×
  • Create New...

Important Information

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