Why you should not use Labview in a control environment

 

• Not deterministic Since you have no control of threads on how and why they are set. There is no way that you can force the code to be deterministic. LV hides the threading to try to remove users from having to deal with treading models. The problem is how you make it deterministic if you have no control of the priority and implementation of threads. If you do not understand coding then this is a good thing, but if the users do not understand coding then maybe they should not be coding. For example I can have a thread taking from 1 to 6 seconds to execute. How can I fix this if I cannot see what is blocking it from executing as that is hidden from me. Is there a critical section blocking or a thread blocking. The nice thing with forcing the user to write the code is that they have to physically create threads and handle critical sections. Since they create it then they are forced to understand it.
• Loading libraries Loading any VI contributes loading everything that is referenced. Therefore if you just want to look at one VI it must load everything. This in turn makes a simple view tedious and time consuming.
• Wait for new technology up to 5 Years New methods introduced with Visual Studio have about 5 year lag time once Microsoft releases it until Lab View adds it to their code. Of course this add in is only available when you buy new software. No free service packs. Example Task based threading available since 2010 will reduce thread time x10, but is not available in Lab View today.
• Data type conversions Converting data types like class or objects are convoluted and hard to understand. For instance if I just want to take an object and then pull out the states of the object to log them it takes an awful lot of effort. In CSharp this is a simple override (object)obj.
• Cost VS professional is $700 with unlimited releases, while Lab View is running at over $4,000. Debug versions will cost you $900 per computer to run Lab view. $$$$ So we have 300 PC in the factory 300 x 900 = $270,000 for license. By the way if you want the fixes to the LV bugs you will have to pay for another license upgrade. More $$$.
• Licensing Lab View and all NI products are licensed to the machine and not the developer. So you are limited to where you can run it. VS is per developer on any machine.
• Speed The execution speed of Lab View is x1000 slower than CSharp. For instance I ran a test loop in CSharp and the loop time was 24 uSecs. The same functionality in Lab View was 24 mSecs throwing out all the loading of Lab View and just using loop execution time.
• Limited functionality Lab View basically limits you the functionality of their controls. Can only base your coding on what vi building blocks NI has deemed you need, therefore you must change your coding to fit into their available block sets. This in its self would be a major rejection of the type of software to use. You cannot limit a developer to force change to program flow based on you lack of methods to do that code. This puts a major limit on what you can do with this code. Will increase development time substantially and make building models to prove out test cases impossible.
• Deviates to far from normal coding The deviation from standard code is so different from c, c++, and c# that it will not even allow for code method reuse. For example string manipulation is not following the same syntax. I am not sure why you would deviate from standard string format syntax when at the end of the day the low level coding of Lab View is a call cpp, C#. Why would you change the format so then when you build the code you have to reconvert the format back.
• Vi Model selections The help groups will show vi models with jpg views. The problem is you have to try to find the vi’s they are calling in the jpg’s. This waste time as some of them do not even exist or are hard to find.
• Coding Diffs vi graphical contents make it extremely hard to do differences on the code line to try to find the changes between versions. Since lab view can only do diff on vi’s in memory it basically cannot do diff on PVA projects, as the links will not work on loading. Therefore the only option you have for diff is manually review the vi’s on separate PC’s. Normal textual based code allows for complete differences in the code to be made with an easy in determining the changes that were made. Since you have to open the project to do diff the file you want to diff must be renamed. Also you cannot open two different files with the same name. How can you compare when you have to rename to open. Diff is essentially worthless for big projects as all it will do is circle a vi diff abstractly. It will not highlight the actual diffs.
• Vi stored in memory LV has to store everything in RAM just to try to pretend it is fast. The problem with doing this in large projects is that all available memory is hogged up by LV. In order to make changes to a file outside of LV you have to make LV release it from memory.
• How do you find functions When looking at functions all you get are pictures of the functions, then you have to try to find a match like finding squares. If they were smart they would have an option to right click and find the functions in the tool panel. That way it would take you straight to the function you are needing.
• Crashes repeatably Easy to make debugger crash while doing simple things like find in the code view. Not a stable program.
• No Backwards compatibility of vi If you update Lab view to a newer version then all the vi that you make changes to are no longer compatible with the old version. Basically you cannot maintain code between versions of Lab View. No changes can be made with the new version or all other tools are force to upgrade to use them.
• File links are auto created NI creates the file links automatically, but if they are broken or changed then there is no way to manually fix them. You have to go into each vi and try to remove it and hope it fixes it for you. In a lot of cases it cannot fix them and then you have dangling links to deleted files. File links tend to be updated once you close project, this should be a button to update links instead of close and reopen projects. Then you can hope it fixes them or breaks code once reopened. For some links you physically have to open the vi then allow it to fix links. How tedious is this going to be on a large project.
• Cannot find broken vi Lab view will just ignore broken vi’s and build the project. The problem is the broken vi is not found until the vi is called. Therefore you can have a lot of bugs in the code just waiting to blow up when the vi is called.
• Wires! Everywhere! The paradigm of using wires instead of variables makes some sort of sense, except that for anything reasonably complex, you spend more time trying to arrange wires than you do actually coding. Worse, finding how data flows by tracing wires is tedious. Especially since you can’t click and highlight a wire to see where it goes – clicking only highlights the current line segment of the wire.  And since most wires aren’t completely straight, you have to click through each line segment to trace a wire to the end. [edit: A commenter pointed out double clicking a wire highlights the entire wire, which helps with the tracing problem]
• Spatial Dependencies. In normal code, it doesn’t matter how far away your variables are. In fact, in C you must declare locals at the top of functions. In Lab VIEW, you need to think ahead so that your data flows don’t look like a rat’s nest. Suddenly you need a variable from half a screen away? Sure you can wire it, but then that happens a few more times and BAM! Suddenly your code is a mess of spaghetti.
• Verbosity of Mathematical Expressions. You thought low-level BLAS commands were annoying? Try Lab VIEW. Matrices are a nightmare. Creating them, replacing elements, accessing elements, any sort of mathematical expression takes forever. One-liners in a reasonable language like MATLAB become a whole 800×800 pixel mess of blocks and wires.
• Inflexible Real-Estate. In normal text-based code, if you need to add another condition or another calculation or two somewhere, what do you do? That’s right, hit ENTER a few times and add your lines of code. In Lab VIEW, if you need to add another calculation, you have to start hunting around for space to add it. If you don’t have space near the calculation, you can add it somewhere else but then suddenly you have wires going halfway across the screen and back. So you need to program like it’s like the old-school days of BASIC where you label your lines 10, 20, 30 so you have space to go back and add 11 if you need another calculation. Can’t we all agree we left those days behind for a reason? [edit: A commenter has mentioned that holding Ctrl while drawing a box clears space]
• Unmanageable Scoping Blocks. You want to take something out of an if statement? That’s easy, just cut & paste. Oh wait no, if you do that, then all your wires disappear. I hope you remembered what they were all connected to. Now I’m not saying Lab VIEW and the wire paradigm could actually handle this use case, but compare this to cut & paste of 3 lines of code from inside an if statement to outside. 3 seconds, if that compared to minutes of re-wiring.
• Unbearably Slow. Why is it when I bring up the search menu for Functions that Lab VIEW 2010 will freeze for 5 seconds, and then randomly shuffle around the windows, making me go back and hunt for the search box so I can search? I expect better on a quad core machine with 8 gb of RAM. Likewise, compiles to the real-time target are 1-5 minute long operations. You say, “But C++ can take even longer” and this is true. However, C++ doesn’t make compiles blocking, so I can modify code or document code while it compiles. In Lab VIEW, you get to sit there and stare at a modal progress bar.
• Breaks ALT-TAB. Unlike any other normal application, if you ALT-TAB to any window in Lab VIEW, Lab VIEW completely re-orders Windows Z-Buffer so that you can’t ALT-TAB back to the application you were just running. Instead, Lab VIEW helpfully pushes all other Lab VIEW windows to the foreground so if you have 5 subVIs open, you have to ALT-TAB 6 times just to get back to the other application you were at. This of course means that if you click on one Lab VIEW window, Lab VIEW will kindly bring all the other open Lab VIEW windows to the foreground, even those on other monitors. This makes it a ponderous journey to swap between Lab VIEW and any other open program because suddenly all 20 of your Lab VIEW windows spring to life every time you click on.
• Limited Undo. Visual Studio has nearly unlimited undo. In fact, I once was able to undo nearly nearly 30 hours of work to see how the code evolved during a weekend. Lab VIEW on the other hand, has incredibly poor undo handling. If a subVI runs at a high enough frequency, just displaying the front-panel is enough to cause misses in the real-time target. Why? I have no idea. Display should be much lower priority than something I set to ultra-high realtime priority, but alas LabVIEW will just totally slow down at mundane things like GUI updates. Thus, in order to test changes, subVIs that update at high frequencies must be closed prior to running any modifications. Of course, this erases the undo. So if you add in a modification, close the subVI, run it, discover it isn’t a good modification, you have to go back and remove it by hand. Or if you broke something, you have to go back and trace your modifications by hand.
• A Million Windows. Please, please, please for the love of my poor taskbar, can we not have each subVI open up two windows for the front/back panel? With 10 subVIs open, I can see maybe the first letter or two of each subVI. And I have no idea which one is the front panel
  and which is the back panel except by trial and error. The age of tabs was born, oh I don’t know, like 5-10 years ago? Can we get some tab love please?
• Local Variables. Sure you can create local variables inside a subVI, but these are horribly inefficient (copy by value) and the official documentation suggests you consider shift registers, which are variables associated with loops. So basically the suggested usage for local variables is to create a for loop that runs once, and then add shift registers to it. Really LabVIEW, really? That’s your advanced state-of-the-art programming?
• Copy & Paste . So you have a N x M matrix constant and want to import or export data. Unfortunately, copy and paste only works with single cells so have fun copying and pasting N*M individual numbers. Luckily if you want to export a matrix, you can copy the whole thing. So you copy the matrix, and go over to Excel and paste it in and……….suddenly you’ve got an image of the matrix. Tell me again how useful that is? Do you magically expect Excel to run OCR on your image of the matrix? Or how about this scenario: you’ve got a wire probed and it has 100+ elements. You’d like to get that data into MATLAB somehow to verify or visualize it. So you right click and do “Copy Data” and go back to MATLAB to paste it in. But there isn’t anything to paste! After 10 minutes of Googling and trial and error, it turns out that you have to right click and “Copy Data”, then open up a new VI, paste in the data, which shows up as a control, which you can then right-click and select “Export -> Export Data to Clipboard”. Seriously?!? And it doesn’t even work for complex representations, only the real part is copied! I think nearly every other program figured out how to copy and paste data in a reasonable manner, oh say, 15 years ago?
• Counter-Intuitive Parameters. Let’s say you want to modify the parameters to a subVI, i.e. add a new parameter. Easy right? Just go to the back panel with the code and tell it which variables you want passed in. Nope! You have to go to the front panel, right-click on the generic looking icon in the top right hand corner, and select Show Connector. Then you select one of those 6×6 pixel boxes (if you can click on one) and then the variable you want as a parameter. Lab VIEW doesn’t exactly go out of its way to make common usage tasks easy to find.
• No separation of concerns. The vi’s do not show any separation of concerns. Modern software should be setup where the code is separate between the GUI and the back end. This movement of MVVC was implemented to make the GUI and code separate to maximize code reuse. It looks like Lab view has not bought onto this since the vi method has no separation.
• Calling classes. When you invoke a class there is no way to see what class was involked, I am expecting to be able to see the classes and where they are coming from. You cannot view where the class is being called from by clicking on the involker. How can you tell what the code is running if you cannot know what it is calling. (Come on NI, that is just poor)
• No try and catch. Try and catch is not supported so any bugs will kill the application and generate an exception error. You cannot have robust code if you cannot handle exceptions.
• Excruciatingly complex. Simple coding written in lab view gets exceeding complex to implement not to mention maintain. I can do the same thing in Csharp with 1/10 the amount of code and complexity. Why would someone even think that this is the proper code to use?