Jump to content

Antoine Chalons

Members
  • Content Count

    705
  • Joined

  • Last visited

  • Days Won

    17

Antoine Chalons last won the day on April 9

Antoine Chalons had the most liked content!

Community Reputation

75

About Antoine Chalons

  • Rank
    The 500 club
  • Birthday September 10

Profile Information

  • Gender
    Male
  • Location
    Lausanne Area

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1999

Contact Methods

Recent Profile Visitors

5,984 profile views
  1. 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. Do you really need/want to support 32 bit? I mean... if it's for vision, you probably use a large size of memory, no? I wish I could offer my collaboration but calling external code is not really my cup of tea, so I'd probably be mostly useless anyway. If you are interested in getting in touch with tensorflow users to have their feedback, get in touch with me via PM.
  3. 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.
  4. I've never tried that, do you have a link to the thunderbolt extention specs? I'd be curious to know if it works well. I think camera-link is not the best option for new product design, my first advice would be to look into CoaXPress. Plus NI-PCIe 1430 and 1433 almost went EOL about 18 month ago.
  5. Pre-2009 Wow... how for back do you go? The mythical 7.1?
  6. 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.
  7. 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!
  8. Graftek Imaging the website does give a few words about the history : https://graftek.biz/aboutus
  9. Ok, thanks a lot for the detailed explanations. I'll stick with the ogsetup.exe
  10. 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?
  11. 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?
  12. 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
  13. Cool! What tool have you used to import the whole SVN repo with all the revision into the Git repo? Is it a feature in Github?
  14. I can download the files from this thread just fine. I'll try sending you a private message with the VI
  15. When I had to pick one, the options I considered were : DQMH AF JKI SMO G# ALOHA my own that would be much better than all of the above combined I picked DQMH because I love the API tester the scripting tools, also I feel there is a somewhat large community adoption and support.
×
×
  • Create New...

Important Information

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