does labview have a future?

[X___]

46 minutes ago, Rolf Kalbermatter said:

Why?

Easy and we'll know what we are using. It's an academia thing, I guess, where a mistake haunts you for the remainder of your career, unlike in industry. You know, miles vs kilometers...

I suppose we need to "follow the rules about filling out the form to document our concerns" too!

[Rolf Kalbermatter]

22 hours ago, X___ said:

Easy and we'll know what we are using. It's an academia thing, I guess, where a mistake haunts you for the remainder of your career, unlike in industry. You know, miles vs kilometers...

I suppose we need to "follow the rules about filling out the form to document our concerns" too!

If you really want to spend a lot of time and effort into this, the more promising way would be to simply start developing an Advanced Analysis Library replacement directly around the Intel Math Kernel Library.

That DLL interface you are talking about is mostly a historical burden carried over from when NI was still developing their own Advanced Analysis Library. Around 7.x days they decided that they could never compete with the girls and guys who knew probably best on this planet how to tickle a few percentage more of performance out of Intel CPUs, because they worked at the company who had developed those CPUs and so NI replaced the in-house developed AAL Math Library with the Intel Math Kernel Library. The DLL interface was left intact so there was little to be changed on the VIs that made up the AAL, but internally most functions in that DLL call more or less directly into the Intel MKL.

Spending lots of time for the documentation of that proxy wrapper DLL is not very useful. There are very few secrets in there that you couldn't learn by reading the official documentation for the Intel MKL.

Edited June 12, 2021 by Rolf Kalbermatter

[X___]

17 hours ago, Rolf Kalbermatter said:

If you really want to spend a lot of time and effort into this, the more promising way would be to simply start developing an Advanced Analysis Library replacement directly around the Intel Math Kernel Library.

That DLL interface you are talking about is mostly a historical burden carried over from when NI was still developing their own Advanced Analysis Library. Around 7.x days they decided that they could never compete with the girls and guys who knew probably best on this planet how to tickle a few percentage more of performance out of Intel CPUs, because they worked at the company who had developed those CPUs and so NI replaced the in-house developed AAL Math Library with the Intel Math Kernel Library. The DLL interface was left intact so there was little to be changed on the VIs that made up the AAL, but internally most functions in that DLL call more or less directly into the Intel MKL.

Spending lots of time for the documentation of that proxy wrapper DLL is not very useful. There are very few secrets in there that you couldn't learn by reading the official documentation for the Intel MKL.

Then we agree that it would be best to release the source code, since this would point directly to another culprit. And BTW, as we discussed in another thread, I believe that there are still some "native" (as in NI brewed) implementations of some of the analysis routines (with their associated corner case bugs).

This being said, regarding password protected VIs, I just ran into a LV Analyzer error due to one of the VIs calling one of the User Tags VIs (which are protected because they probably use some super-secret call which are not supposed to be left in the hands of peons). Which is pretty ironic, considering that both are written by the same NI developer...

Edited June 13, 2021 by X___

[ShaunR]

4 hours ago, X___ said:

I just ran into a LV Analyzer error due to one of the VIs calling one of the User Tags VIs (which are protected because they probably use some super-secret call which are not supposed to be left in the hands of peons)

If it's something like Get User Tag.vi or Set User Tag.vi, I can guarantee there is nothing in there that would surprise you.

[X___]

 

3 hours ago, ShaunR said:

If it's something like Get User Tag.vi or Set User Tag.vi, I can guarantee there is nothing in there that would surprise you.

My ignorance amazes me, sometimes most of the time...

[ShaunR]

57 minutes ago, X___ said:

 

My ignorance amazes me, sometimes most of the time...

Nah. You just haven't had a misspent youth like I have ;)

[Rolf Kalbermatter]

19 hours ago, X___ said:

Then we agree that it would be best to release the source code, since this would point directly to another culprit.

As far as if NI could do that legally, yes they could. If they want to? Why should they? Are you releasing all your source code as Open Source?

And this is really meant seriously. Propose a meaningful business case why NI should release that source code if you were a manager at NI! And don't forget all the technical support questions of noobies trying to peek in that code, thinking they can fix something and then boom, everything goes haywire. There is no business case in the current NI software model for this. Unless NI decides to go .Net Core with their software, which I don't quite see happen yet.

Open Sourcing components that are not just nice to have libraries that you can more or less throw out in the wild according to the motto: Take it as is, improve it on your own or leave it! is only causing additional work and issues without solving anything.

Edited June 14, 2021 by Rolf Kalbermatter

[X___]

7 hours ago, Rolf Kalbermatter said:

As far as if NI could do that legally, yes they could. If they want to? Why should they? Are you releasing all your source code as Open Source?

And this is really meant seriously. Propose a meaningful business case why NI should release that source code if you were a manager at NI! And don't forget all the technical support questions of noobies trying to peek in that code, thinking they can fix something and then boom, everything goes haywire. There is no business case in the current NI software model for this. Unless NI decides to go .Net Core with their software, which I don't quite see happen yet.

Open Sourcing components that are not just nice to have libraries that you can more or less throw out in the wild according to the motto: Take it as is, improve it on your own or leave it! is only causing additional work and issues without solving anything.

Well, I presented a clear business case against locked diagrams: they prevent the Analyzer (a NI product) from working correctly. Following your logic, I wonder why nobody has thought of preventing people from using pointers in C because they could crash their software?

Providing detailed documentation is not a NI priority, we know that. Fine. Their market share is plummeting in the software development arena, especially in academia. Are the two correlated? Maybe.

I am certainly not at war with NI, and my leaving NI forums a few years ago is due to the fact that I felt that my inputs had zero value for me (no practical influence on NI's development). I am stating my opinion, and you are free to dislike it.

As for my own code, I have released some of the source code of my "lighter" programs. Releasing and documenting 1,000s of VIs that nobody will ever look at is not something that I can afford as a single developer. But truly, I wished this was all made easy and natural by NI, and there was a striving community of LV developers in academia that could vet and pinpoint bugs in some of my code. I am lamenting the fact that 25+ years of investment in this development environment are going down the drain and will leave no legacy because what was a truly brilliant concept got killed by corporate miscalculation ($2.5K annual single license originally - or maybe more -, no mechanism for forward compatibility from version to version).

Time for a python fork with graphical IDE? 

Edited June 14, 2021 by X___

[X___]

17 hours ago, ShaunR said:

Nah. You just haven't had a misspent youth like I have ;)

So NI knows that their password protection is a joke, but they are still using it. No comment.

[hooovahh]

1 hour ago, X___ said:

So NI knows that their password protection is a joke, but they are still using it. No comment.

The design choices of LabVIEW make it impossible to encrypt the entire file.  The block diagram has to be readable at some point which means access to it will be possible in a variety of ways.  I'm sure there's some kind of compromise between restricting VIs to a specific target and build of LabVIEW, and the current implementation.  I just wanted to highlight the fact that the solution to protect the block diagram isn't a simple one.

[ShaunR]

2 hours ago, X___ said:

So NI knows that their password protection is a joke, but they are still using it. No comment.

NI have said on many occasions that the VI diagram password system is not intended to protect IP - more of a disincentive to fiddle with diagrams (think of operators on a production line). NI's recommendation if you require stronger security is to remove the diagrams.

Edited June 14, 2021 by ShaunR

[X___]

2 hours ago, ShaunR said:

NI have said on many occasions that the VI diagram password system is not intended to protect IP - more of a disincentive to fiddle with diagrams (think of operators on a production line). NI's recommendation if you require stronger security is to remove the diagrams.

Now that makes perfect sense.

[Rolf Kalbermatter]

5 hours ago, X___ said:

So NI knows that their password protection is a joke, but they are still using it. No comment.

Consider the diagram password equivalent to your door lock. Does it prevent a burglar to enter your home if he really absolutely has set his mind on doing so? Of course not!

Is it a clear indication to the normal law abiding citizen to not enter? You bet!

There is no simple way to protect a diagram that the compiler needs to be able to read in order to recompile the program (for a different version, platform or whatever) without having a fairly easy way to also  peek into it for the person truly wanting to. In fact there are many ways to circumvent that. You could patch the executable to skip the password check when trying to open a diagram or you can locate the password hash and reverse its algorithme to get back at the password. The only problem is that this is an MD5 hash. So it is not a simple reversible algorithme, but MD5 is not a secure hash anymore, since with enough CPU power you can find a string (it does not necessarily have to be the original password since multiple arbitrary sized character sequences will eventually map to one single hash code) that results in the specific hash. It may take a few days and will certainly contribute to the global warming 😀, but it can be absolutely done. Chances are that that CPU power may be more productive in terms of money when directed at mining of cryptocurrency, even with the current dive in value. Another approach is to simply replace the password hash in the file with the hash for the empty password (which means unprotected). It's not as simple as replacing 16 bytes of data in a file with a standard byte sequence, since that hash is also computed over some of the binary data of the VI file, but it's also not impossible.

Why they didn't make it more secure? The only way to do that would be to truly encrypt it but then you also need the password to be able to recompile the code. But then you can just as well remove the diagram when distributing the VIs, as that diagram has not real additional value anymore, except that you as password owner don't have to maintain two versions, one without diagram to give to your user, and one with it for your maintenance and further development. You would end up with the problem to have to distribute your VIs for every LabVIEW platform you want to support or hand out the password to your users in order for them to be able to compile it for a different platform or version. 

Basically to come back to our door lock: The security you are expecting would be pretty much similar to replacing all windows and doors in your house with a concrete wall and only leave one single door that is heavily steel enforced, with quadruple high security locks and self shoot installation in case of entering the wrong code more than 3 times. Very secure but absolutely not comfortable or practical and potentially lethal to your family members and friends.

Edited June 14, 2021 by Rolf Kalbermatter

[X___]

12 hours ago, Rolf Kalbermatter said:

Consider the diagram password equivalent to your door lock. Does it prevent a burglar to enter your home if he really absolutely has set his mind on doing so? Of course not!

Is it a clear indication to the normal law abiding citizen to not enter? You bet!

There is no simple way to protect a diagram that the compiler needs to be able to read in order to recompile the program (for a different version, platform or whatever) without having a fairly easy way to also  peek into it for the person truly wanting to. In fact there are many ways to circumvent that. You could patch the executable to skip the password check when trying to open a diagram or you can locate the password hash and reverse its algorithme to get back at the password. The only problem is that this is an MD5 hash. So it is not a simple reversible algorithme, but MD5 is not a secure hash anymore, since with enough CPU power you can find a string (it does not necessarily have to be the original password since multiple arbitrary sized character sequences will eventually map to one single hash code) that results in the specific hash. It may take a few days and will certainly contribute to the global warming 😀, but it can be absolutely done. Chances are that that CPU power may be more productive in terms of money when directed at mining of cryptocurrency, even with the current dive in value. Another approach is to simply replace the password hash in the file with the hash for the empty password (which means unprotected). It's not as simple as replacing 16 bytes of data in a file with a standard byte sequence, since that hash is also computed over some of the binary data of the VI file, but it's also not impossible.

Why they didn't make it more secure? The only way to do that would be to truly encrypt it but then you also need the password to be able to recompile the code. But then you can just as well remove the diagram when distributing the VIs, as that diagram has not real additional value anymore, except that you as password owner don't have to maintain two versions, one without diagram to give to your user, and one with it for your maintenance and further development. You would end up with the problem to have to distribute your VIs for every LabVIEW platform you want to support or hand out the password to your users in order for them to be able to compile it for a different platform or version. 

Basically to come back to our door lock: The security you are expecting would be pretty much similar to replacing all windows and doors in your house with a concrete wall and only leave one single door that is heavily steel enforced, with quadruple high security locks and self shoot installation in case of entering the wrong code more than 3 times. Very secure but absolutely not comfortable or practical and potentially lethal to your family members and friends.

Sorry, I didn't realize that I was trying to "steal" diagrams. Thanks for clarifying.

[LogMAN]

Here is a KB article with information about the design decision of password protection: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LvFSAU

Quote

In order for LabVIEW to be able to recompile a VI, it must be able to read the VI’s block diagram. Because LabVIEW must be able to execute this without prompting the user for a password, LabVIEW cannot use any strong encryption to protect the VI’s block diagram.

Not sure why strong encryption would be impossible. One way to do that is to store a private key on the developer(s) machine to encrypt and decrypt files. Of course loosing that key would be a disaster 

[Rolf Kalbermatter]

46 minutes ago, LogMAN said:

Here is a KB article with information about the design decision of password protection: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LvFSAU

Not sure why strong encryption would be impossible. One way to do that is to store a private key on the developer(s) machine to encrypt and decrypt files. Of course loosing that key would be a disaster 

And how would you suppose should your client, who wants to use this library on a cRIO-9064 (just to name one of the currently still possible options which are Windows 32-bit, Windows 64-bit, Pharlap ETS, VxWorks, Linux 64-bit, MacOS X 64-bit, Linux ARM) recompile it without having access to the key? Sure with asynchronous encryption you don't have to publish your private key but then you are still again in the same boat! If you want to give a client the possibility to recompile your encrypted VIs (in order to not have to create a precompiled VI for each platform and version your clients may want to use), LabVIEW somehow has to be able to access it on their machine. And if LabVIEW can, someone with enough determination can too.

Sure enough, nowadays LabVIEW could be turned into LabVIEW 365 and you could host your code on your own compile server and only sell a VI referrer to your clients. Anytime a client wants to recompile your VI, he has to contact your compile server, furnish his license number and the desired compile target and everything is easy peasy, unless of course your compile server has a blackout, your internet provider has a service interruption, or you go out of business. All very "nice advantages" of software as a service, rather than a real physical copy.

[LogMAN]

12 hours ago, Rolf Kalbermatter said:

And how would you suppose should your client, who wants to use this library on a cRIO-9064 (just to name one of the currently still possible options which are Windows 32-bit, Windows 64-bit, Pharlap ETS, VxWorks, Linux 64-bit, MacOS X 64-bit, Linux ARM) recompile it without having access to the key? Sure with asynchronous encryption you don't have to publish your private key but then you are still again in the same boat! If you want to give a client the possibility to recompile your encrypted VIs (in order to not have to create a precompiled VI for each platform and version your clients may want to use), LabVIEW somehow has to be able to access it on their machine. And if LabVIEW can, someone with enough determination can too.

You are right, I haven't thought it through. Source access is required to recompile, which makes any encryption/obfuscation/protection annoying to reverse engineer at best.

12 hours ago, Rolf Kalbermatter said:

Sure enough, nowadays LabVIEW could be turned into LabVIEW 365 and you could host your code on your own compile server and only sell a VI referrer to your clients. Anytime a client wants to recompile your VI, he has to contact your compile server, furnish his license number and the desired compile target and everything is easy peasy

[GregSands]

Does it help to re-ask the question as "where should LabVIEW have a future?" It is not difficult to name a number of capabilities (some already stated here) that are extremely useful to anyone collecting or analyzing data that are either unique, or much simpler, using LabVIEW. They're often taken for granted and we forget how significant they are and how much power they unlock. For example (and others can add more):

• FPGA - much easier than any text-based FPGA programming, and so powerful to have deterministic computational access to the raw data stream
• Machine vision - especially combined with a card like the 1473R, though it's falling behind without CoaXPress
• Units - yes no-one uses them , but they can extend strict programming to validation of correct algorithm implementation
• Parallel and multi-threaded programming - is there any language as simple for constructing parallel code? Not to mention natural array computations
• Real-time programming
• Data-flow - a coherent way of treating data as the main object of interest, fundamental, yet a near-unique programming paradigm with many advantages
• and all integrated into a single programming environment where all the compilation and optimization is handled under the hood (with almost enough ability to tweak that)

Unfortunately NI appear to be backing away from many of these strengths, and other features have been vastly overtaken (image processing has hardly been developed in the last 10 years, GUI design got sidetracked into NXG unfortunately). But the combination of low-level control in a very high-level language seems far too powerful and useful to have no future at all.

[MarkCG]

I used to think the future of LabVIEW was bright. I thought CompactRIO was amazing and thought everyone would want to use it for all kinds of control systems. LabVIEW was just intuitive to me, jobs and well paying contractor gigs were plentiful and hitched the first decade of my career to it. Got to do some interesting things but decided it wasn't such a smart idea to be locked to the fortunes of one company, whose decisions didn't really make sense to me. Yes LabVIEW will be around in the same way LISP is. 20 years from now people will reminisce about visual programming and how advanced it was and all the things you can do with it that other languages still can't. It's not going to save it. Too niche, too proprietary, too different.

If you still have a few decades left till retirement I would absolutely learn python at the minimum. If you like making machines do things there is the whole industrial automation world that is adjacent to LabVIEW / Test and Measurement where skills can transfer over. I personally spent some time learning how to use Beckhoff's TWINCAT platform and think that's a great entry point.

[Lipko]

As long as there will be any kind of support and it will run on my machine and executables will be buildable with it and runtime engines will run properly, it will be my primary application/tool builder environment. The ability to qickly throw together GUI intensive (and not so intensive) specialized applications is still unmatched for me (though I admit I haven't looked into recent tools).

The intuitive parallellism is also good, but to be honest there were only a few occasions where I did actually need it (control with DAQ).

Okay, my career is not based on Labview at all.