Jump to content
martin_g

Distribute .lvproj with Block Diagrams Removed

Recommended Posts

Hi, 

 

I've got an RT project which I need to distribute the source code, My .lvproj contains multiple .lvlibs + deployment info for a cRIO.

 

I'd ideally like to create a distribution that includes the .lvproj file and also removes the block diagram of certain VI's in this distribution, if I can't do that I'd at least like to password protect some key VI's.

 

Options I've tried:

 

- ZIP file - this includes the .lvproj and all the RT info I need, but there is no way to add passwords or remove a block diagram.

 

- Source distribution - I can remove block diagrams, but I can't include the .lvproj file with my RT info. 

 

I could go in and add passwords to every VI in my hierarchy that needs protection, but that will take a while, and I don't require the passwords in my development copy, just in the distribution.

 

Is there a way to do what I want? 

 

Cheers

 

Martin

Share this post


Link to post
Share on other sites

 

I could go in and add passwords to every VI in my hierarchy that needs protection, but that will take a while, and I don't require the passwords in my development copy, just in the distribution.

 

 

https://decibel.ni.com/content/docs/DOC-19943 This makes adding passwords easier.

Share this post


Link to post
Share on other sites

But a password does NOTHING to secure your IP. The password keeps casual users from modifying VIs, such as folks using your test bench. If you want to breach that wall, it is a wall made of tissue paper. Always has been.  If you want to secure your IP, remove the block diagram when you save. - 

 

Removing the block diagram is a much better solution, assuming you can live with the fact that the code will not be able to be recompiled for other versions of LabVIEW.  You can edit the code linked by jcarmody to save without block diagram.  Right now there is a constant for it.

Share this post


Link to post
Share on other sites

In the Build Specifications/Source File settings, I see all options of passwording, removing FP and BD for individual files and groups of them, even for Source Distribution builds. Never occurred me to try it out, but isn't it enough?

Share this post


Link to post
Share on other sites

Thanks jcarmody, hoovah. I'll try modifying that VI as my goal is to protect my IP - so removing the block diagram is my preference.

Ensengre - you do get all of those options when creating a source distribution, which is great. But you cannot include .lvproj information in a source distribution. I've got a compactRIO setup in my project, and I need to include that in the distribution that I create.

Share this post


Link to post
Share on other sites

Hi, 

 

I've got an RT project which I need to distribute the source code, My .lvproj contains multiple .lvlibs + deployment info for a cRIO.

 

I'd ideally like to create a distribution that includes the .lvproj file and also removes the block diagram of certain VI's in this distribution, if I can't do that I'd at least like to password protect some key VI's.

 

Options I've tried:

 

- ZIP file - this includes the .lvproj and all the RT info I need, but there is no way to add passwords or remove a block diagram.

 

- Source distribution - I can remove block diagrams, but I can't include the .lvproj file with my RT info. 

 

I could go in and add passwords to every VI in my hierarchy that needs protection, but that will take a while, and I don't require the passwords in my development copy, just in the distribution.

 

Is there a way to do what I want? 

 

Cheers

 

Martin

 

Manually add the .lvproj file to the project (i.e. itself) then it will appear in the build source distribution.

Edited by ShaunR

Share this post


Link to post
Share on other sites

Manually add the .lvproj file to the project (i.e. itself) then it will appear in the build source distribution.

That could work, but you'd probably have to make sure the lvproj links to the source distribution rather than the original. I doubt app builder will do anything with the lvproj file.

 

With the source dist option, you should also double check that your bitfile works correctly if you're using cRIO.

 

Back to the original question, I see this as being two fundamentally different issues. 

 

Basic protection is pretty simple as described above, you can use either a source dist or a lvlibp and remove the block diagrams. From an IP protection standpoint, you may want to remove front panels+turn off debugging on the code as well. After all if you can see the inputs and outputs to a function and run it, there might be a way to glean whats going on. Depends on what you're looking for/how paranoid you are. Also depending on your level of paranoia, I'd recommend walking through this series of whitepapers and making sure you at least understand what you are and are not doing to protect your system (just skip to the three links at the bottom): http://www.ni.com/white-paper/13069/en/

 

 

The second issue is less clear, as I'm not sure what benefit you get from including the lvproj. It seems like the easiest answer is what shaun said or to make a post-build VI which copies the lvproj file to the source dist's location. But I am curious why this is important. To me you'd normally build your exe in dev, make an image, and then use the image for deployment. I'm confused why you'd want to make a specific configuration but not build an exe out of it. 

Share this post


Link to post
Share on other sites

The second issue is less clear, as I'm not sure what benefit you get from including the lvproj. It seems like the easiest answer is what shaun said or to make a post-build VI which copies the lvproj file to the source dist's location. But I am curious why this is important. To me you'd normally build your exe in dev, make an image, and then use the image for deployment.

 

I tried adding the .lvproj file within the project but got an error message that 'An item with this path already exists in the project.' Shaun's suggestion is very simple, which I like, so I'll try a post build VI to copy the .lvproj.

 

Why I want to do it is a bit complicated, but briefly; deployment has been done with an .exe. There is now a requirement to share the entire source code for the project and I want to protect some IP within the project.

Edited by martin_g

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By vivante
      Hallo, I have done some manteinance to an application compiled with LabVIEW 2012. That app has an installer, so my users can upgrade it easily. I usually install the application on the same machine where I develop with LabVIEW and after I try the installation procedure on a clean machine to see if issues arise. Today have seen that on the development PC, the executable runs fine. Instead on the clean machine, the following message appears after that the application has loaded the panel.       Have you seen this message in past? I have found some posts here: other users have found the same issues, with older versions of LabVIEW.   forums.ni.com/t5/LabVIEW/VI-has-an-error-of-type-2208-42308-302208/td-p/1540496   I have upgraded the DAQmx drivers on the clean machine , but the issue remains.   Any idea?
    • By pumprace
      Hi all,
      My question deals with how best to distribute large collections of lvclasses that implement a 'plugin' architecture. Some background first:
      I've been reading the lava forum for about two years and dove head first into LVOOP about a year and a half ago. As such I may be calling what I have 'plugin' when a better term already exisits for what I'm doing; please correct me if there is a better term.
      The application I've got implements essentially a dynamic form that allows the user to structure properties of a tdms file with information needed to complete some kind of test on one of our products. This 'blank' file is distributed to the correct test stand where it can be used to spawn data files that are populated with information from each test run. Pretty common task I think.
      To implement this I have a four-tiered class hierarchy:
      Generic Metadata -> Generic Product Series -> Specific Series -> Specific Model
      The bulk of the code and all the interfaces are implemented in the first two classes with the last two providing overriding methods as needed for whatever specific product is being worked with (which is why I'm calling it a plugin architecture). This means the last two classes represent an ontology of the company's product line, which means there are a LOT of classes there. Last count I had 24 Specific Series and around 1000 Specific Models.
      In the development environment, I load the first two classes as constants on the block diagram then use a factory to load the specific classes from disk at run time by building a relative path off of the top level class path. This works well because all the classes are part of my project and are therefore easy to manage on disk, but I need to be able to build this application into an executable and distribute it to the entire company.
      How can I include the classes in my distribution and load them at run time without making maintenance a nightmare?
      Would packing each class and its methods into an llb, including all the llbs in an installer, and loading each class from the llb at run time work? Would my dynamic VIs work from inside llbs? Would packed project libraries be a better choice? Do I have to put the entire class hierarchy inside the library or can I compile the top two classes into the exe?
      Lots of questions!
      Also I tried to upload a diagram of my class hierarchy, but I think my webfilter is preventing me from uploading anything.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.