01-05-2016 02:21 AM
Hi all!
Hope, someone knows this and can solve the mystery.
We use LabView for over 10 years now. We provide password protected VIs to our customers, which is no problem in standard custom applications.
Now a customer claims that they cannot compile a Veristand custom device with these password protected VIs.
Is this a general problem of Veristand (I cannot find anything in the KB, nor on the internet) or is it related to the LabView version our VIs are made with?
We are still using LabView 7, for a reason. To offer widest compatibility for users, because good old, nice, fast and small LabView 7 is still being used.
We don't know what version of Veristand is used by the customer, but let's assume it's the most recent one.
TIA!
01-05-2016 04:03 AM
Hello,
If I'm not wrongt, in order to run with the latest VeriStand version, the custom devices must be (re)compiled using the LabVIEW version used by this VeriStand version (LabVIEW 2014 or 2015 - not sure).
Best regards
01-05-2016 04:06 AM
Thanks, but this is actually what I wrote. Yes, the Veristand device has to be compiled be recompiling the supplied VIs. Customer claims it doesn't work.
According to NI (http://digital.ni.com/public.nsf/allkb/831F38C46BCBDADE8625793A0054BB19), recompilation of password protected VI should work.
01-05-2016 04:14 AM
Re,
OK, sorry but I'm just a member and not able to help you more, I guess a NI support member will do.
Regards,
01-05-2016 04:35 AM
No need to say sorry.
I'm also just a member in hope that some other member or NI product customer with Veristand in use has come across this problem.
01-05-2016 05:19 AM
"Building" a custom device is just a source distribution to llb. So you can easily test it. It should be possible to include password protected vis.
My guess is, that jump from LV 7 to 2015 is too big and vi gets broken for whatever reason (dependency, datatypes change, ...) So I would first try to open that vis in LV 2015 and see.
Another solution to protect you IP is to build your set of vis to packed project library. It is using different namespace, so no problem with vis with the same name in memory. Disadvantage is, that you need to build it for each version of LV, that customer is going to use.
As example see our: https://github.com/NIVeriStandAdd-Ons/Scan-Engine-Custom-Device-Classes and calling custom device: https://github.com/NIVeriStandAdd-Ons/Scan-Engine-Custom-Device
~Jiri
CLA, CTA
01-05-2016 06:18 AM
Thanks Jiri. This is the first and only customer with this problem since we use LabView and doing what you suggest would not only take a lot of extra effort, but also destroy the downwards compatibility to LV7. When loading the LV7 created VI in LV 2013 or newer, warnings may appear, but they work. So far, no problem.
My thought now is: the customer should open the VIs in his LabView version, let's say 2015, then mass compile them, then insert them into their Veristand device.
Then they are saved for the newer LV version, including updated data types and Veristand compilation should not fail anymore.
01-05-2016 06:33 AM
Exactly. The question is if the vis are broken before the build, opened in LV 2015... If so, why?
CLA, CTA
01-05-2016 06:46 AM - edited 01-05-2016 06:48 AM
I don't know. We are not in direct contact with the customer. All we heard is like "does not work, give password". If we open our VIs in LV 2015 - no problem, not broken.
I suggested my thought to them, let's see how it turns out.