Antoine Chalons

I fully agree with that, my use case is in fact quite simple and over-uses abstract classes in some occasions.

well, there might be a little more to it. when this option is enabled, the package build goes through but the "rename" was skipped ; unless I completely misunderstand the feature, I see that as a bug.

I enabled the "Do Not Compile on Build" option (in Source File Settings section) and the package building worked and took a lot less time than before As I mass compile my source folder anyway before building the package, am I risking anything? Why is this option "not recommended"?

(message first posted on jki forum, but traffic there seems very low...) I get this error when building my package with VIPM, previously the package was building fine. It always took a long time (~15 to 20 minutes) to build this package because it's quite large (~78 classes, 1200+ VIs). Since the last successful build I've only added some methods in the classes. Mass compiling the folder containing the source code doesn't report any issue. Error 66 is descibed in LabVIEW as 'The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server on the server side.' I've check this and other (smaller) package still build fine. Sources are in LV 2019 32 bit I'm using the latest version of VIPM 2021.1 b2754 Any suggestions?

I have a class hierarchy that has 9 levels of inheritance, 78 classes in total and I probably will reach 100 classes at some point. I have not really noticed any specific issue with this, project load time is similar to other project of similar size but with tiny inheritance trees. The only issue I ran into is that if I mass compile from the project, it will take days but if I mass compile from the tools menu, just a few minutes. (see discussion on NI forums about this)

if I remember well moving from OpenG to MGI made the code run much faster.

To get ride of this issue, I used a modified version of the MGI read / write anything (https://www.vipm.io/package/mgi_lib_read_write_anything/) The modification was adding a "close file" primitive both when reading and writing the file, and when writing also a "flush" before the close.

I've seen this, I can't open your code because I'm in LV 2020. I'm guessing when the power cut happened, the file ref had been opened and not closed yet. I don't know which VIs you use for to read/write your INI, but my I suggest to make sure that any time you access the files, you do use open file, read or write and close file as soon as you're done.

could you save back the VI to LV 2018 please?

done

Lots of questions here, I will simply point you to vipm.io from when you'll be able to get VIPM related info. There are 4 'levels' of VIPM, free, community, pro and entreprise, see differences here https://www.vipm.io/download/ As far as I know VIPM is not a tool that will let you manage license subscription in your product, for this I think the best starting point is on NI forums : https://forums.ni.com/t5/Developer-Center-Resources/tkb-p/7307 As a side note, I think handling different types of licenses of your product is not an easy task, good luck with that!

Your reply came as I was typing my edit... Thanks

Has anyone been able to make this work on Linux desktop? I use LV 2020 SP1 (therefore 64 bit) on Ubuntu 20 I ran to install libcrypto.so but at the first call of the so "OpenSSL_add_all_digests" I get error 15 "resource not found" and indeed if in the CLFN I put the full libcrypto.so path, the "OpenSSL_add_all_digests" is not in the "function" list edit : I guess the answer is RTFM With help from a co-worker we could make it work on Linux, multiple functions have different names, will post the VI soon.

pour les refs activeX, oui je pense qu'il faut les fermer. Pour les refs de controles, je te renvoie à la présentation de Darren Nattinger : https://forums.ni.com/t5/LabVIEW/Which-references-need-to-be-quot-Closed-quot/m-p/3775021#M1063802 Tu peux lire l'entier du fil... mais c'est un peu long

Also, I think you can find advanced examples if you go to Help > Find examples > vision

I don't have Vision Dev module anymore so I can't send you code, sorry. There are a few things to consider, here, what is your camera (brand, model)? And do you have a fast drive to save on (SSD)? I'm asking this because most probably, the code you wrote is limited by the fact acquisition and saving are done in the same loop. And I doubt that - even with an SSD - your computer would be able to acq+save 100k images per second, even if those images are small in resolution. Also note that saving to TIFF might not be the fastest option. I think you have to go for a slightly more elaborated architecture and use 2 loops, one for acquisition and another one for saving. About 10 years ago I made a system that was acquiring 4k images per second (tiny images, 128*1000 8bit monochrome), it had to work without an SSD not we were limited in the duration of acquisition depending on the RAM, the concept was to fill the RAM for as long as we could, stop the acquisition and save to disk. But the first step for you I guess is to calculate the throughput in Mbytes /s that you'd like to achieve, I'd say 200 Mbytes or lower you culd probably stream to disk untill it's full.

Do you mean you want to attract python people so they can use ML in LabVIEW?

VIs from DSC / user management let you check the user/group of currently connected user and based on that you can decide to do anything you wish, refuse keyboard entry, value change on controls, etc... To be clear, I'm not saying you should use the DSC module, I'm simply saying it could be used also to do that. Now... do you already have a licence for it? If not, just implement your own user management. If yes, not too fast, using it requires to understand how it stores the information about the domain (groups/users) etc.

In the past I used the DSC module from NI, it lets you create groups and users in those groups, then in any VI of your project you can hide front panel elements based on groups. There is a palette with a few VIs to list / change users. Pretty handy, and if you change user during execution, automagically LabVIEW handles the rules that you defined. You can't change changes "rules" during execution. DSC module is Windows only. edit : a runtime is needed for deployed EXEs, I'm pretty sure the runtime is free, at least it was in the past.

I've just watched this :

hey... wait a minute, does this mean that when a class is loaded on host and on RT target, it will be locked, and we'll be stuck with this limitation untill the end of LabVIEW?

It was very nice to have you as an NI insider participating on LAVA, wish you a lot of fun in your new mission.

I think it's called project provider, there is a special interest group on NI Forums I've never fiddled with this but some have, here's a few other links : - https://forums.ni.com/t5/Developer-Center-Resources/Customize-the-LabVIEW-Project-Explorer-Using-the-Project/ta-p/3532774?profile.language=fr - https://forums.ni.com/t5/LabVIEW-Project-Providers/Project-Providers-Documentation/m-p/3492573#M285 -

That doesn't shock me at all. The activity on LAVA is - and has been for quite some time - very low. Edit : ... in quantity of course

I'm one of those. I'm not sure how young lads do their internet search but if you look-up "labview forum" LAVA is in the top 3