LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLLs - Export of VI mandatory

And as regards the project, personally, I would have one project for the operator interface and not bring in any UUT specific code. I would also have one project for each UUT.
0 Kudos
Message 11 of 14
(551 Views)
>No. When a DLL is created, it is just like an exe. The block diagrams are removed. with an
>exe or dll, you now have the option a creating a debuggable version that keeps the block
>diagrams but if you don't choose that, then they are safe. In older versions of LabVIEW,
>you could rename the exe to llb and view the names of the separate VIs in the the exe but even
>that is not possible anymore. There have been some extended discussions here and on
>info-labview about the security of password protected and block diagram removed VIs. Do a
>search and give them a look.

A small addition to this. You can reverse-engineer a DLL to see the code in assembly. So, if you
think you have some algorithms that you want to protect, you should consider this.
0 Kudos
Message 12 of 14
(543 Views)
One project per UUT makes sense, but I have some quesitons.  Is there any concern with common/shared VIs (utilities, drivers) showing up in several DLLs.  OR, should all those common things be in their own DLL.  If that's the case, how are these other DLLs referred to/referenced in the UUT DLLs?
0 Kudos
Message 13 of 14
(526 Views)
Hi MrBean,
I would say put the shared resources in their own DLL, and make wrapper VIs that call into the shared resources.  That way, if the resource interfaces change, you don't have to change all the accessors.  Or you can keep the shared resources seperate, but have a single access point to all shared stuff in his app that wraps the interfaces to the shared resources.
Hope this information helps.

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support

0 Kudos
Message 14 of 14
(504 Views)