How to protect block diagram with password from editing but be able to still view it.

[RobertoMendez]

Hello,
I'm a test engineer in a manufacturing facility, recently we have been having issues with technicians messing up the test code, I know the most obvious answer is to make executables of our programs, but the maintenance team is reluctant to go for this route as they would not be able to see the code and put probes in case of a failure, so I've been investigating about Source control or a more simple solution would be to be able to block de VI with a password, but Labview only offers the option of protecting with password without being able to see the block diagram without it, or to protect without password and be able to see the block diagram but no editing.

So my question is, is there any way to password lock the editing of the block diagram but keep them to be able to see the block diagram?
I hope I was totally clear, I've searched in the forum for this topic but I haven't found a solution as I wanted, thanks in advance!

[crossrulz]

A couple of options I would consider:

1. Use the "Lock without Password" option.  Yes, it doesn't really protect the VI from being edited.  But it is a simple barrier to avoid accidental changes as the user will have to go into the settings and unlock the VI.

2. Build your libraries into Packed Project Libraries that your main application uses.  These are compiled (ie uneditable), but you can enable debugging which will allow the block diagrams to be viewed and probed. 

[Kyle97330 · Accepted solution]

Assuming you use Active Directory, you could set the folder that the VIs are in to be read-only except for people in certain permission groups, i.e. developers and admins would be the only ones with access.

Or...

If you deploy the software to the station with some form of source control, you can add some code to your program that does the following on startup:

1. Get all dependencies recursively of the top VI (apart from vi.lib)

2. Find all those VI locations on disk

3. Check them all for changes not committed to source control

4. If any changes are found, refuse to run unless an override password is provided (which you would not give to the technicians causing the problem)

You'd need to password protect the diagram of just the top main launcher VI in this case (to prevent removal of the check...) and nothing else.

[RobertoMendez]

Thanks Kyle, your second suggestion is the route i'm going to take!