LabVIEW
Why labview 2019 cant open VIs written in 2020?
@1984 wrote:
Consider this: You have a LabVIEW VI and save some configuration to a file. You can do this in many ways, for instance simply saving the configuration structure into a binary file. Now you update your software and add an extra element to that cluster. Bam all your old configuration files are worthless. This is just reading old existing files! Doing the opposite by trying to make the format future proof requires even more work! LabVIEW VIs are MUCH more complex than a simple cluster flattened to a byte stream. The work for making it read old files correctly is already immense. To make sure it works, requires tons and tons of regression tests before every single new release, and yes that applies even for minor bug fix releases. Testing for an unknown yet future format compatibility is totally impossible until someone develops a time machine. It would also at least exponentially increase the number of regression tests that need to be run, with absolutely no guarantee that a new version won't somehow require a format change for a new feature that the old routines simply can't handle!
I understand the analogy but comparing a work of regular developer to a company which supposed to develop a programming language is not fair at all. As individuals - normally - we dont have resources to make super long term decisions thats why our file structures tend to change from time to time. On the other hand NI had 30 years to figure out a file structure flexible enough across version to version. Its just simply hard to believe that the structure of the VIs really changes for every release. If NI really has to rework the structure on a yearly basis then they really have a problem.
They don't have to rework the structure on a yearly base and they don't do that. The problem is that if even 0.01% of the structure of a VI's binary data changes, the old code can't load it. To change that, the format of how VIs are saved, would need to be considerably changed, with much more redundant information too. This could be acceptable but the work to do so is immense at this point and simply won't happen unless someone with a yearly many multi million dollar budget for NI products demands this for whatever reason. And for pretty much everybody out there, LabVIEW simply is a tool they use and they won't pay a few million bucks to NI for such a feature.
For NI there is extremely little incentive to implement this. It costs tons of money, is almost impossible to really get right and sells not one single extra NI product. You don't need a bean counter economic genie to see that this simply is not gonna happen. Even my very simple engineering brain can do the math and see that it is not going to fly.
They tried to do that with LabVIEW NXG. The naive promise was that moving to an XML format would allow this more easily and at the same time also would allow more easy diffing of the VI changes. The reality is that XML doesn't make it easier but just differently complex. There is simply no universal diffing tool that is able to diff an XML file in a generic matter without explicitly also knowing about the internal data structure of what the XML file represents. And the same or worse would happen with JSON or any other text format. It's a very difficult problem to solve to the point that the effort to do it is exorbitant expensive in a way that nobody really wants to do it for the little extra gain it offers. You may feel that it is a great feature as it allows you to look at new VIs with your old LabVIEW 2009 license. Great feature for you, but bad feature for NI as it takes another reason away for users to upgrade to the newest version.
Unless you can offer reasonable proof to NI that there is some advantage for them in implementing this feature that offsets the effort needed to develop it, it simply is not going to happen.
@AeroSoul wrote:
@rolfk wrote:Unless you can offer reasonable proof to NI that there is some advantage for them in implementing this feature that offsets the effort needed to develop it, it simply is not going to happen.
Good luck with that, considering the subscriptions and all.
It's pretty much independent of that. The net benefit for such a change is highly negative no matter what distribution model NI would use for their software. The least relative negative effect would be if NI would give away LabVIEW for free. 😀
But I think we all can agree that that would be a completely unsustainable model anyways.
@rolfk wrote:
@AeroSoul wrote:
@rolfk wrote:Unless you can offer reasonable proof to NI that there is some advantage for them in implementing this feature that offsets the effort needed to develop it, it simply is not going to happen.
Good luck with that, considering the subscriptions and all.
It's pretty much independent of that. The net benefit for such a change is highly negative no matter what distribution model NI would use for their software. The least relative negative effect would be if NI would give away LabVIEW for free. 😀
But I think we all can agree that that would be a completely unsustainable model anyways.
Don't say that, it works for many companies. I wonder how the revenue is on IDE vs HW. It could well be that HW sale would increase due to higher adoption.
@Yamaeda wrote:
Don't say that, it works for many companies. I wonder how the revenue is on IDE vs HW. It could well be that HW sale would increase due to higher adoption.
That's how it worked for LabVEW in the past. LabVIEW as it was developed would not have been possible in itself over such a long period. It was cross subsidized by NI hardware sales, despite NI not wanting to admit that publically. LabVIEW was the tool that sold NI hardware back in the days when the computer based measurement hardware was the craze of the moment. All other competitors tried to compete in price, NI competed with very good LabVIEW support for their hardware. And people were willing to pay a higher price for NI hardware in exchange for easy use of it in a sexy programming environment that did not necessarily require a computer science degree in order to get something working.
With the new NI and computer based measurement being more of a side note than the NI core business, and each department within NI being its own profit center, things substantially changed.
@1984 wrote:
With the new NI and computer based measurement being more of a side note than the NI core business
Just for curiosity, could you elaborate on this a bit more?
NI appears to be moving away from Test & Measurement and more towards corporate infrastructure. The acquisition of Optimal+ was a big sign of this. At NI Connect (previously known as NI Week), notice that the main focus of the keynotes was System Link. Go back 5+ years ago and the emphasis at NI Week was getting data and connecting everything through LabVIEW.
@1984 wrote:
So all in all it seems to be a business decision. I wouldnt be surprised if a simple downconverter tool could be release which can convert higher VIs to lower labview version even without having LV on the PC.
crossrulz already answered your second question. As to this remark, if you didn't know, NI is a stock traded company with stock owners expecting a ROI that at least beats the market (which it hasn't really lately but they are still doing fine).
I'm sure your boss would be very delighted if you went to him and told him:
You: "You see I have this great idea that makes our products so much easier to use for our users. Can I work a few months on it?"
Boss: "Does it sell more products?"
You: "Hmm, no not really. It allows our users to use our products much longer before having to buy a new one."
Boss: "Get out of my eyes! Do you expect me to spend MY money to make our users buy less products? Do you want to still have a salary next month or rather sit on the street?"
