Antoine Chalons

WOW, thx for sharing this, it looks great! Is there any OS restrictions? I'm thinking about NI Linux RT.

pre-2010 I used one on a project (it was a firewire camera at the time), it was to check the temperature of a incandescent object. nothing too fancy.

Which camera model are we talking about? I believe the recent ones are GigE & GenICam compliant so the set attribute vi from IMAQdx with the correct attribute name (to be found in the camera user manual) should do the job.

As mentioned here : ?

it's ok to cross-post, but please mention it : https://forums.ni.com/t5/LabVIEW/camera-postion-stuck-in-3D-picture-control/m-p/3989985#M1138502

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.

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.

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.

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.

Pre-2009 Wow... how for back do you go? The mythical 7.1?

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.

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!

Graftek Imaging the website does give a few words about the history : https://graftek.biz/aboutus

Ok, thanks a lot for the detailed explanations. I'll stick with the ogsetup.exe

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?

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?

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

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?

I can download the files from this thread just fine. I'll try sending you a private message with the VI

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.

NI offfers an electrical power toolkit : http://zone.ni.com/reference/en-XX/help/373375G-01/

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

Please post a picture 😂

I agree with Rolf, I think most people are not as strict as you are. And while we're at it, what version of english should be used? American english or British english or any other flavour. I thought about this when I read capitalising spelt with "z" 😂

maybe this thread can help you, at the end it give the list of forbidden characters.