Leaderboard

The year that it all went wrong

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there. Following is not directed at you Shaun but at anyone being high in the arms about the insufficient protection password protected VIs give them to protect their oh so precious IP: Password protection of diagrams is not meant to protect your IP. There exists only one really secure way to protect your IP, and that is to put it in a heavy steel safe, destroy all copies of your idea and dump the safe in the North Pacific above the Mariana Trench. Save of some alian race with super high tech, nobody will be able to get at those secrets. Chances are however high that someone else has already developed the same idea independently and will go to market with it and earn some money with it. Another slightly less secure means is to hire a whole army of lawyers who will involve anybody into a legal battle who might even just appearing to try to steal that IP, so that they can fight for the rest of their life, robbing them of any time to invest into monetizing the stolen idea. Both of them are highly unpractical and costly! Get over it and accept that password protection of diagrams is only to keep out the nosy. If you do need to protect your IP don't distribute the source at all! Bite the bullet and remove at least the diagram. Yes it's inconvenient as such VIs can only be loaded into the LabVIEW version in which it was created and also only on that platform but anything else means LabVIEW has to be able to get at the diagram somehow without knowing the password (or worse yet store the password in the VI somehow too) and that also means that anybody with enough determination will be able to circumvent any kind of protection the LabVIEW developers can come up with to prevent others than LabVIEW itself to get at that diagram. I think the best long term protection in that respect is actually the semi annual release cycle of LabVIEW as it obsoletes any of the more promising hacking solutions each time.

But that goes against the reason for having a small compact VI i the first place I am leaning towards this one. Anyone got any comments on the VIs Jim posted? Can it be enhanced? I am thinking that this satisfies the requirements of this review and that it should be used as is.

Well, in any case, it looks like the OpenG version is considerably faster (I see ~20 ms for OpenG vs. ~300 ms for the vi.lib VI), so that answers that, at least.

Over the past couple years I've tried unit testing in various projects. Sometimes successful, sometimes not. Even on those rare occasions when I've been successful I usually felt like I was going in circles with my tests, trying to figure out how to best build and organize them. Unit testing was more of a brawl than a ballet. Several months ago I picked up what is now my second favorite book recommendation (right after Head First Design Patterns,) a gem called xUnit Test Patterns. If you're doing OOP, understand patterns, and want to improve your ability to deliver good software, this is the book to get. (There's even lots of information on the website if you don't want to purchase the book.) The book is written for xUnit frameworks so it is a natural fit for JKI's VI Tester. There are a few minor things VI Tester currently doesn't let you do, such as inherit from a test class, but 96+% of the book is directly applicable to your Labview projects.

This is kind of obvious I guess, but a for loop which is not iterated, will not pass a reference through. This means if you're controlling your loop using auto-indexing (as I was), and for the use case where there is no data in the input array, any operations which had pass through references will return an error in the next operation to require that reference. In my case, an enqueue operation. I guess this is by design, though I don't see why it should be. I know I can handle this but manually checking the size of the input array and using case structure. Or just split the queue reference and not pass it through (order of operation is already ensured by error terminals in any case). Just curious as to the logic of this, given we have the ability to control For Loops by auto-indexing. Regards, Alex

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and give up the ability to recompile for different platforms and different LV versions.You're just lucky no one has build an equivalent of Reflector for LabVIEW. It can regenerate C# source code from the binary compiled DLLs or EXEs, even without the debug info being included. In the modern world, you have three choices: don't share your code in the first place only give it to users who aren't dedicated to getting into your code or for whom it is cheaper to buy it than to crack it get a lawyer to enforce your copyright and terms of use. Small claims court is your friend here. Those are your options. Let's just say his next PXI chasis will be "calibrated differently" and leave it at that.

Too often. OCD.

I understand what you are asking, but a closer examination (triggered by Steve's comment) leads me to conclude your question is meaningless. How so? If there was really "nothing wrong with" the code you would have no desire to change it. The very fact that you made a change means you believe something was wrong with it. (Assuming, of course, your intentions are to improve the code base.) Why do I bother pointing out what appears to be an irrelevant non-issue over the question's semantics? Because underlying your question is an unstated assumption that, in my opinion, is the leading cause of software rot. "to avoid an "ugly solution" that was robust and really had nothing wrong with it" This phrase implies functionality is the only thing that matters--as long as the software functions correctly it is good. I disagree. Functionality only relates to the external quality of the software. Professional developers should be just as concerned with the software's internal quality as well. We all know block diagram style plays a huge role in how easy it is to read and understand what is happening. There are other things that contribute to internal quality as well: Choosing descriptive names for sub-vis, creating clean apis for the components, project explorer organization, consistency throughout the application, descriptive comments, application architecture, etc. Most LV developers do reasonably well keeping block diagrams organized, often to the point of obsession. (How frequently do we shift a wire 1 pixel just to fix a bent wire?) Somewhat fewer of them spend much time on the other things I listed. I think I can boil down your question to this: Is spending time improving internal quality worthwhile? Absolutely. Continuous refactoring, one of the principles of agile development, is all about improving internal quality. The trick--and the root of many disagreements between developers--comes in figuring out how much quality is needed. What one dev sees as a quality improvement another dev sees as a waste of time or unnecessary obfuscation. I know you smilied this comment, but I am compelled to respond to it as if it were a serious response anyway... Less is not more. Less is just what it says it is... less. Promoting 'less is more' implies we should develop applications with minimalism being our goal. (Minimal what can be debated... minimal # of vis, minimal size, minimal dev time, etc. I'll collectively refer to them all as stuff.) That, imo, is the wrong way to think about it. We should be trying to create the correct amount of stuff to satisfy all the project's requirements, not just the functional requirements. 'Less is more' is a useful reminder when people are in the habit of overdoing something. (Makeup, salting foods, etc.) In my opinion the LV community by and large errs on the side of not enough stuff, not too much stuff.