VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Custom Veristand device not to be compiled with password protected VIs?

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!

0 Kudos
Message 1 of 9
(5,126 Views)

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

0 Kudos
Message 2 of 9
(5,114 Views)

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.

0 Kudos
Message 3 of 9
(5,111 Views)

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,

0 Kudos
Message 4 of 9
(5,108 Views)

No need to say sorry. Smiley Happy

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.

0 Kudos
Message 5 of 9
(5,102 Views)

"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

0 Kudos
Message 6 of 9
(5,092 Views)

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.

0 Kudos
Message 7 of 9
(5,085 Views)

Exactly. The question is if the vis are broken before the build, opened in LV 2015... If so, why?

CLA, CTA

0 Kudos
Message 8 of 9
(5,079 Views)

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.

0 Kudos
Message 9 of 9
(5,076 Views)