DLLs vs locking VIs

[mrbean]

We're looking ahead to the time we have to deliver our sw to the customer,and I'm not sure how to best resolve the issue of disallowing the operators the ability to edit/view the VI source (block diagrams).  The way I see it, we can do one of three (possibly more) things.

1) We can lock all VIs before they ship and make them password protected.  We wouldn't have to change any of our directories, and there would be little overhead; (2) We could place all our VIs into a DLL.  This (I believe) would be quite cumbersome, in that each VI would have to manually be added to the DLL.  Does LabVIEW allow you to select multiple VIs when adding?  A problem I see with DLLs is that you have to create a LabVIEW project file to manage it.  At first, project files seem like a nice organizational tool, but since they're merely softlinks to the actual files, you can quickly get into trouble. (3) Have both the Development and Base Deployment License (for TestStand and LabVIEW) installed on the target, and activate only the Base Deployment license.  The user can then only run the Operator Interface - and not the Sequence Editor (thus not allowing them to alter parameters and VIs).

Assuming my assumptions/arguments are correct, is there a recommended approach when delivering to the customer?

[TCPlomp]

It depends on what you are selling/delivering.

If you deliver a full program I would compile it into an executable.

If you deliver a driver set that is only applicable for one LV version remove the block diagrams, that way they won't be recompiled but you have to release a new version for every LabVIEW release (if I'm not mistaken it is advised to create a new set for a x.x.1 version.

If you deliver a driver set that is applicable for multiple LV version having a blocked block diagram is a good option.

Ton

[Dennis_Knutson]

First of all, i doubt that you could legally install the development license on a deployed tester. Only the base should be installed and when the customer needs to make changes, they can install their copy of TestStand development or the TestStand debug license. Second, the only thing installed on the deployed tester should be the LabVIEW run-time. Without the LabVIEW development system, no changes can be made.

I don't quite understand your concerns about LabVIEW projects. It is a great organizational tool that should have been used from the beginning, imho. Creating a single or multiple dlls is not an issue. You can have multiple top level VIs in a single dll. Personally, I prefer to create a dll for each step type that I create. If I find a bug, I only have a small dll to re-create and re-deploy. Unlike your situation though, my sequences go to a contract manufacturer and I don't even send the source code, just the dll. I would think you would have just the opposite where you have to provide the source code to the customer that paid for it.

[mrbean]

I'm not too clear on your responses.  But then again, my question was not exactly intelligible.  Here is a bit more info.  We're delivering a customized (LabVIEW) version of the TestStand Operator Interface, along with multiple sequence files (one or more for each UUT we're testing), a number of (LabVIEW) Configuration Property Loader (.cfg) files, and the source code (VIs) called by the various steps within the sequences.  We don't want the build/delivery process to be soooo complex that we come to a grinding halt every time we have to make a change.  However, we don't want our source code visible to the customer. 

(1) Given our situation, would 'compiling into an executable' be a good idea?  We already have one for the TestStand Exec
(2) What exactly did you mean by "remove the block diagrams, that way they won't be recompiled"

[Dennis_Knutson]

Removing the block diagrams is a very nasty thing to do to a customer if you really mean to prevent the customer from viewing/modifying the block diagrams and not just the TestStand operator. When you no longer exist as a custom software provider (and such companies go out of business or change hands with a high degree of regularity), the customer is left with code that can't ever be run with a newer version of LabVIEW. If it's really the customer, how did you find one so naive as to not insist on owning the source code when the project is complete?

[mrbean]

We have several 'customers'; one gets the (raw) source, but the end user just gets the Exe.  This end user will NEVER be modifying/seeing the source.  It's this end user to which I refer.  We have two 'testers'.  Both have LabVIEW and TestStand development environments on them right now, while we develop.  One of these testers will be delivered in a year or so with (hopefully) the test code, etc to test some UUTs.  Since we've already bought the LabVIEW/TestStand licenses (2 of each), is it not legal to send these along with the Tester?  Assuming it's legal, is it the right thing to do?  You said, "the only thing installed on the deployed tester should be the LabVIEW run-time" - Is this because the source is in LabVIEW, AND the TestStand Operator Interface we're using is the LabVIEW version?  Given that I too (like you) won't be delivering the source code, would you recommend your DLL approach?  How do you handle VIs that are common to multiple steps?  I use the LabVIEW project to contain/build my TestStand Operator Interface, but the thought of creating a project for the test code, and creating many, many, DLLs frankly scares me.  Any comforting thoughts?

[Dennis_Knutson]

The reason I said that only the LabVIEW run-time and TestStand run-time should be installed is if the operator of the deployed system should not have the abiltiy to make changes, there is no reason to give up one of the licenses if you have one to spare. Presumably, you would keep one license. Does the one that gets the source code, have their own license. If you really do have a spare, you might have to do a license transfer but the main point is why put something on a system if it's not needed?

As I discussed in a different thread of yours, I don't use large VIs. I use small custom steps that are very specify. For example, one step type/dll for instrument A, one step type/dll for instrument B, etc. I may call these steps many, many times and with different parameters each time, but overall, there are very few different step types in any given sequence. I think the largest uses no more than 15 different custom steps. Also, I just got a bit irritated whenever I tried to just view a VI's block diagram, being prompted for the password. Yes, you can keep one set of VIs unprotected and another set protected for distribution, but maintaining two sets of files for everything was an extra hassle I just didn't want to deal with. Keeping just a set of password protected VIs always made me worry that someone had used the wrong password. Once a VI is password protected, unless you know the correct one, no one (including NI) can open it.

I haven't played with the deployment utility much and I just upgraded from TestStand 2 to 4, but doesn't the utility give you the option to password protect or remove diagrams when you create the deployment package? If it does, then just use that when the time comes.