Problems with LabVIEW 2017?

[Aristos Queue]

On 10/14/2017 at 0:07 PM, ShaunR said:

I expect you will find that most people that you say buy the new version are on a SSP so they get it anyway even if they are using an older version.

CEIP data shows for a wide swath, it isn't just "buy"... it's also "use."

[shoneill]

14 hours ago, Aristos Queue said:

Frequently, and with increasing frequency. There really is little difference between a full release and an SP1 release at this point -- the cadence is about 6 months apart, and each has bug fixes you might need/want. With the binary-backward-compatibility of 2017 and later, more barriers to upgrading disappear. It is more likely that the main release will have new features, but the various drivers/modules might add support in the SP1, which, from customer perspective, is new features. So, while I understand the hesitancy to upgrade until the SP1, the reasons for that hesitancy have decreased dramatically over the last five years, dropping to zero hesitancy for some segments of the LV user base.

Any correlation between the segment of the LV user base who adopts non SP1 versions and the ones targetted with the "Programming Optional" marketing?

[ShaunR]

20 hours ago, Aristos Queue said:

There really is little difference between a full release and an SP1 release at this point -- the cadence is about 6 months apart, and each has bug fixes you might need/want.

I see you have you marketing hat on

The reason for waiting until SP1 is for others to find all the bugs and for NI to address them. It is a function of risk management and it is far better if no new features are added so that no new bugs arise. 6 months is actually a good time-frame to see what falls to pieces in a new version, what work-arounds are found and if NI will fix it. For this reason I encourage everyone to get the latest and greatest as soon as it hits the ground

If a driver/device isn't in a new version, then there is little reason to upgrade at all if you are dependent on it - so I don't buy that. If a project critical feature is only added in SP1, then it is usually a case of wait for SP2 (for the aforesaid reasons). I've never seen one of those from NI but you do get bug fix updates occasionally so it is a wait for one of those. The "wait for SP1" isn't a LabVIEW thing, by the way. It applies to any new versions of software toolchains (and used to apply to Windows too). Your argument for SP1 is feature driven when, in fact. the hesitancy for the arrival of SP1 is performance and stability driven irrespective of features.

[Aristos Queue]

6 hours ago, ShaunR said:

I see you have you marketing hat on

It's a factual statement: the trend of the last several years is the main release having fewer new bugs and the SP1 release having more new features. I expect these trends to continue, with the probability of a new bug arising eventually being equal between the two releases. NI is being pushed by industry to shorten the overall release cycle considerably. Most software is moving in that direction. Even systems as complex as MS Windows have moved to continuous delivery.

I am not arguing that you should do any particular thing. I am saying that your stated argument for waiting for the SP1 is becoming less and less valid each year. You might have other reasons for waiting, but the bug level isn't as solid a delimiter as it used to be. I am personally somewhat uncomfortable with software having a permanent "level of instability", but that does appear to be the trend across the industry.

[shoneill]

BTW. I just spent the entire day yesterday trying to find out why my project crashes when loading.  No Conflicts, no missing files, no broken files. Loading the project without a certain file is fine, adding the file back when the project is loaded is fine but trying to load with this file included from the beginning - boom crash with some "uncontinuable exception" argument. I have NO idea what caused it but eventually, at 7pm I managed to get the project loaded in one go.  Yay labVIEW.

I don't care how often LV is released as long as bugs in any given version is fixed.  To find the really awkward bugs we need a stable baseline.  Adding new features cosntantly (and yes, I realise fixing a bug is theoretically the same thing but typically a much smaller scope, no?) raises the background noise so that long-term observations are nigh impossible.  I for one can say that the time I spend dealing with idiosyncracies of the IDE is rapidly approaching the time I spend actually creating code.  Crashes, Lockups, Faulty deploys to RT...... While LV may be getting "fewer new bugs" with time, it's the old bugs which really need dealing with before the whole house of cards implodes.

Defining an LTS version every 5 years or so (with active attempts at bug fixes for more time than that to create a truly mature platform) would be a major victory - no new features, only bug fixes.  Parallel to this, LV can have a few "feature-rich" releases for the rest.  Bug fixes found in the LTS can flow back into the feature-rich version.

I've proposed it again and again but to no avail because, hey, programming optional.

I'm annoyed because I want to be productive and just seem to be battling with weirdness so much each day that a "permanent level of instability" just sounds like a joke.  At least my exposure to this instability is icnreasing rapidly over the last years, or so it feels.  And yes, I'm always sending crash reports in.

[ShaunR]

13 hours ago, Aristos Queue said:

It's a factual statement: the trend of the last several years is the main release having fewer new bugs and the SP1 release having more new features. I expect these trends to continue, with the probability of a new bug arising eventually being equal between the two releases. NI is being pushed by industry to shorten the overall release cycle considerably. Most software is moving in that direction. Even systems as complex as MS Windows have moved to continuous delivery.

I am not arguing that you should do any particular thing. I am saying that your stated argument for waiting for the SP1 is becoming less and less valid each year. You might have other reasons for waiting, but the bug level isn't as solid a delimiter as it used to be. I am personally somewhat uncomfortable with software having a permanent "level of instability", but that does appear to be the trend across the industry.

Indeed. That is one [of a couple] of reasons why I still develop in 2009 which is rock solid and arguably more performant than most, if not all the later versions. I only recompile and deploy in later versions as the customer requests (with one notable exception due to event refnums not being backwards compatible). Those later versions will always be SP1 for the stated reasons. If I hit a project stopping bug during recompilation and deployment in the later versions, I always have the option to go back to a point before the bug was introduced. So far that has happened 5 times which isn't much but I would have been screwed if I didn't work this way..

If you are saying that there will be no difference between SP1 versions and release proper, then you should just drop the pretence that SP1 is a "service pack" and rename it to a "feature pack".

Suppliers want to sell new stuff, bugs and all (software always has bugs, right? We just have to accept it as a fact of life!). Developers want both new and existing stuff to just work (new stuff has bugs but they will be identified and addressed in time until there are none).

My development Windows boxes have automatic updates turned off. In fact, it has the all services associated with updates disabled-that's how much I distrust them. I now have to re-enable the services,find out which updates are being offered, then read the M$ website and manually select the updates to apply. If there is a "rollup" (aka SP) then it will be installed. The SP never went away, you were able to just get it piecemeal as it became available. But by god, do I have to jump through hoops to prevent "Father M$ knows best". Just take the latest furore with "Game Mode" as a recent example. Of course.. That issue only affects those who jumped right in to get the latest and greatest version. Time has passed. M$ have admitted there is a problem. It will be fixed and then I might (only might, not definitely) update the one and only windows 10 box.

The experienced will wait. The impetuous tempt fate.

 

3 hours ago, shoneill said:

Adding new features cosntantly (and yes, I realise fixing a bug is theoretically the same thing but typically a much smaller scope, no?)

No. A feature is an implementation of a requirement (new code). A bug is a failure of an implementation (existing code).

Edited October 18, 2017 by ShaunR

[Tim_S]

7 hours ago, shoneill said:

Defining an LTS version every 5 years or so

Got to second a LTS version. It is challenging to develop a product with LabVIEW with the version updates and which drivers support which versions. My development cycle has been about every 3 years, so I'm never calling tech support on the most recent versions of LabVIEW.

[Aristos Queue]

6 hours ago, ShaunR said:

If you are saying that there will be no difference between SP1 versions and release proper, then you should just drop the pretence that SP1 is a "service pack" and rename it to a "feature pack".

I kind of expect NI marketing to do that in a few years. Maybe it won't ever happen for the current LabVIEW platform, but LabVIEW NXG is being designed for this brave new software world. It's not my call to make, and it is really hard to push back against the idea when the whole software industry, including our own vendors and many downstream dependents, are moving in that direction. Like ShaunR, I have reservations about the whole idea, but I am observing it as a successful pattern in many other companies, both vendors and users, so I'm keeping an open (if doubtful) mind.

 

[ShaunR]

35 minutes ago, Aristos Queue said:

I kind of expect NI marketing to do that in a few years. Maybe it won't ever happen for the current LabVIEW platform, but LabVIEW NXG is being designed for this brave new software world. It's not my call to make, and it is really hard to push back against the idea when the whole software industry, including our own vendors and many downstream dependents, are moving in that direction. Like ShaunR, I have reservations about the whole idea, but I am observing it as a successful pattern in many other companies, both vendors and users, so I'm keeping an open (if doubtful) mind.

 

Philosophically speaking. The whole software industry is going to get a big kick in the gonads in the not too distant future for abusing what was actually a fairly good idea. NIs history of lagging the trends by about 10 years means it will probably roll it out when the first strike hits home. The first red flag is the "customer experience" feedback which immediately saw me reaching for process manager, regedit and firewall rules. M$ have abused it so much that there are now calls within the EU to legislate against it and it has already become synonymous with spyware amongst users.

It won't be too long until the software industry is viewed with the same contempt as banking.

Edited October 18, 2017 by ShaunR

[shoneill]

7 hours ago, ShaunR said:

No. A feature is an implementation of a requirement (new code). A bug is a failure of an implementation (existing code).

Well, the idea meant was that fixing a bug or implementing a new feature changes the environment for other code so both may or may not have an effect on the prevalence of any other given bug to raise its head at any given time.  The larger the change to code, the more disruption and the more disconnect between tests before and after the change.  Intent is irrelevant.  Features and bugs may overlap significantly.

[ShaunR]

17 minutes ago, shoneill said:

Well, the idea meant was that fixing a bug or implementing a new feature changes the environment for other code so both may or may not have an effect on the prevalence of any other given bug to raise its head at any given time.  The larger the change to code, the more disruption and the more disconnect between tests before and after the change.  Intent is irrelevant.  Features and bugs may overlap significantly.

The probability of side effects with new features is orders of magnitude greater than fixing a bug that has been localised to a single function. The amount of effort is also disproportionate as a bug will already have regression tests and only require a test (or maybe a couple after error guessing) for  that particular case. A new feature will also have more bugs in its test cases because that's also new code.

[0_o]

Back to the topic...

Installing LabVIEW 2017 on the same machine with LabVIEW 8.5.1 causing the later to stop loading. You see the icon of 8.5.1 on the taskbar yet nothing happens.

Removing LV 2017 doesn't help. Reinstalling 8.5.1 doesn't help. Uninstalling all NI products doesn't help. 

Only deleting NI folder in program files and reinstalling 8.5.1 helped.

Reinstalling 2017 reproduced the problem.

Calling NI support resulted in NI telling me that 8.5.1 will get support only if it is over Vista.

For years 8.5.1 was working perfectly over Win10 and only 2017 broke it dramatically with no worning but NOOOooo... It is a Win10 compatibility issue. Yeah right.

I hope that the NI developer that caused that issue will perform a harakiri and I do love LabVIEW.

After the years of having a broken implementation of LVOOP, unlike ShaunR, I went for each update since it really did improve over time but 2017 really stubbed me in the back.

[Tim_S]

1 hour ago, 0_o said:

Installing LabVIEW 2017 on the same machine with LabVIEW 8.5.1 causing the later to stop loading. You see the icon of 8.5.1 on the taskbar yet nothing happens

NI started recommending virtual machines at the last seminar I was at. With the different versions of LabVIEW and drivers it's been the only sane way to manage. My IT is balking at the idea as Microsoft sees each VM as a different PC, so one physical (not-server) PC may get hit for many Windows licenses.

[hooovahh]

For small development stuff in obscure versions Microsoft has VMs available for free download with a multi month time limit that can be extended, and snapshots that can be taken to extend this for quite some time.

And many large companies have site licenses for Microsoft products where they aren't paying for each install with a full install price but sometimes just a key to use on that site as much as they want.

But yeah if you don't fit into one of those two categories VMs are a bit harder to do large scale.

Something as old as 8.5 should probably be in a VM just due to the legacy OS that it officially supports.  Still I get the frustration.

[smithd]

On 10/13/2017 at 10:38 PM, Aristos Queue said:

planet581g: Have you contacted NI tech support? That's exactly the kind of thing that we'd like to hear about. I'm not sure why so few people escalate those sorts of issues to us, but I've noticed over the years that if users can restart and keep working, they never report the issue.

It seems to me there is MASSIVE pressure to avoid escalation of these sorts of issues. You say "people don't escalate these things", I say "AE listens to my issue and says they need an encapsulated reproducible case with a bow on top for them to escalate". 

On 10/14/2017 at 5:56 PM, Aristos Queue said:

If nothing else, filing a sufficiently outraged bug report, complete with a rub-your-face-in-it reproduction case (so the bastards at Microsoft can't claim I'm making it up) is really cathartic. Substitute "NI" for "Microsoft"... I bet it can help your morale. :-) 

Thats interesting...to me, a lot of the issues I have with labview are what I'd describe as "transient showstoppers". For example I had a similar issue where right clicking anything would hang labview, and I needed to go to a class property window. The problem eventually went away, and its not a crash. Because of the AE situation, there is basically no way to provide this feedback to NI in a way they will respond to it. Making a reproducing case is difficult if not impossible, and where I work I can't just provide NI with the whole codebase, so you end up kind of stuck. You might say "a problem like that is hard to solve for any company", and my response is "well it sure seems to happen a lot with labview". 

Edit: Just got round to this thread, another perfect example: https://lavag.org/topic/20325-slow-index-array-of-classes/

"As much as I'd love to dig into the LabVIEW memory manager to truly understand what's happening in the dev environment (not), I am just going to put this in the "no longer a problem" column and move on."

On 10/14/2017 at 7:07 PM, ShaunR said:

Changing versions is a huge project risk. You may get your old bug fixed (not guaranteed, though) but there will be other new ones and anyone who converts mid-project is insane. In fact. I would argue that anyone who upgrades before SP1 is out is also insane.

On the first part, changing versions: definitely agree, and this bit me hard last year. However I'm totally on board with using non-sp1 versions. I have never waited and I've not seen any versions where I considered the major to be any different than the SP in terms of reliability. As an example, I would absolutely take 2015-non-sp over 2014 sp1 any day. 2014 was just a horrible year for labview, don't know why.

On 10/17/2017 at 9:18 AM, shoneill said:

Any correlation between the segment of the LV user base who adopts non SP1 versions and the ones targetted with the "Programming Optional" marketing?

4 hours ago, Tim_S said:

NI started recommending virtual machines at the last seminar I was at. With the different versions of LabVIEW and drivers it's been the only sane way to manage. My IT is balking at the idea as Microsoft sees each VM as a different PC, so one physical (not-server) PC may get hit for many Windows licenses.

Depending on what you develop, linux VMs are an option. You can request a linux labview copy from your salesperson, I believe (or just calling in to support). 

Edited October 19, 2017 by smithd

[Rolf Kalbermatter]

On 10/17/2017 at 3:54 PM, ShaunR said:

I see you have you marketing hat on

Even if he had, he is factually still right. The differences are small in the last few years. That is to say that there haven't really been ground breaking new features in a new release in quite some time. Personally I'm quite fine with that as I rather have a stable development environment than a new UX compatible UI widget set that will be obsoleted by the next Google developer conference or Microsoft cheerleader party again .

That said we still do not start new projects on a non-S1 version of LabVIEW. Everybody is allowed to install the latest version, but what version is used for a particular project is defined by the project leader at the beginning of the project and that is not going to be a non service pack version. Since development of projects is typically always a multiple people task nowadays there is also no room left for someone to just go with whatever version of LabVIEW he prefers. Version changes during a project principally don't happen, with a few very rare cases for longer running projects when a new version of LabVIEW or its drivers supports a specific functionality much better or fixes a fundamental bug. Not even for bugs that can be worked around will we go and upgrade to a new version during a project.

The reason for this is obvious. A LabVIEW program as we write them is not just LabVIEW alone. It consists of all kinds of software components, NI and MS written, third party and in house developments. Any change of a component in this mix can have far reaching consequences that don't always have to be visible right away. For in house developed software we can quickly debug the issue and make a fix if necessary, so there the risk is contained, but for external software it is much harder. It often feels like a black hole when reporting bugs. It's almost impossible to even track down if and when a bug was fixed. This is both for NI and other external software similar, but considering the tight contact with NI it feels like being used. The whole bug reporting feels very like a one sided communication even if I follow threads on the fora. For problems reported there, if there is at all a reaction from some blue bird, it often is a rather standard reaction where the poster is thanked for reporting a problem and then a number of standard questions about version numbers and involved software, which sometimes has no relevance to the problem at hand and sometimes could even be inferred from the first post already if read properly. This sometimes goes on for a few more posts like this and then the thread dies, without any further final resolving post by any blue bird. It may have been solved offline but the reader on the forum doesn't see this. It looks like a back and forth of a more or less related or unrelated question and answer conversation and then it vaporizes like a tiny water stream in the desert.

In addition I'm myself not a proponent of installing always the latest and greatest software version if not really necessary. And developing also tools and libraries for reuse it is again not an option to only develop them for the last version. So even if a bug gets fixed I might not profit from that immediately but due to the feeling of being so disconnected anyways it doesn't even feel like it is getting fixed ever.

[ShaunR]

5 hours ago, rolfk said:

Even if he had, he is factually still right. The differences are small in the last few years. That is to say that there haven't really been ground breaking new features in a new release in quite some time. Personally I'm quite fine with that as I rather have a stable development environment than a new UX compatible UI widget set that will be obsoleted by the next Google developer conference or Microsoft cheerleader party again .

I agree. There have only been two times that I have thought about upgrading my dev environment from 2009 - when the native JSON primitive came out and when I was given Linux versions of 2012. UX doesn't factor into any of this, for me. I moved to Websockets years ago and haven't looked back, being freed from that particular straight jacket.
 

5 hours ago, rolfk said:

That said we still do not start new projects on a non-S1 version of LabVIEW. Everybody is allowed to install the latest version, but what version is used for a particular project is defined by the project leader at the beginning of the project and that is not going to be a non service pack version. Since development of projects is typically always a multiple people task nowadays there is also no room left for someone to just go with whatever version of LabVIEW he prefers. Version changes during a project principally don't happen, with a few very rare cases for longer running projects when a new version of LabVIEW or its drivers supports a specific functionality much better or fixes a fundamental bug. Not even for bugs that can be worked around will we go and upgrade to a new version during a project.

That's a fair comment. But the rule of thumb is "never update until SP1". The premise being to let everyone else find the bugs and work-arounds as they are not costed or planned for. Experience shows that SP1 is generally more stable than the initial release (evidenced from the known issues and bug fix documents). NI may be changing that but that wasn't the case for 2009 and I still argue that that version is more robust, less buggy and more performant than any of the later versions.

Quote

When software meets the real world, it’s not the real world that will yield to your software; you must adapt whatever you’re doing to the circumstances truly at hand. (what Dwight Eisenhower might have said about software :D)

5 hours ago, rolfk said:

The reason for this is obvious. A LabVIEW program as we write them is not just LabVIEW alone. It consists of all kinds of software components, NI and MS written, third party and in house developments. Any change of a component in this mix can have far reaching consequences that don't always have to be visible right away.

Indeed. But here is the rub. I now use other languages for a UI (yields TCPIP segregation). I'm using dynamic libraries for many of the drivers (both in-house and external) and LabVIEW is no longer doing much of the heavy lifting. It has become more of a swappable middleware development choice, albeit with many advantages. My only real requirement is that LabVIEW doesn't break the library interface or TCPIP stack and the prevalence of open source alternatives to NI specific ones is getting better every year.

For prototyping it's still, at the moment, the first tool I reach for. My toolkit built over many years means that I already have most "components" I need to do develop industry standard stuff so most of the little tweaks and new features just make me ask myself "do I want to refactor that to take advantage?" Most of the time the answer is "no" since there is no real change (e.g. conditional tunnel) and the current stuff is optimised, proven and robust.

5 hours ago, rolfk said:

It often feels like a black hole when reporting bugs. It's almost impossible to even track down if and when a bug was fixed. This is both for NI and other external software similar, but considering the tight contact with NI it feels like being used. The whole bug reporting feels very like a one sided communication even if I follow threads on the fora.

On this front I get the distinct impression that at NI; the left hand has no idea what the right hand is doing. AQ recently asked me to converse with some people over there about issues installing LabVIEW.NET (yeah, I know they prefer to call it NXG). Now. I'm not particularly interested in that platform (for obvious reasons) but I can certainly outline the problems I had so said "Sure. Get them to talk to me through Bascamp". For those that don't know. Basecamp is a 3rd party project management platform that partners and toolkit developers are forced to use when communicating with NI.

Several tumble weeds go by, then I get an email from someone at NI asking about it so I send them a Basecamp invite (to join the myriad of people at NI already signed up) in case they don't know how it works either (AQ had used Basecamp for a personal project, but never used it for NI communications). I never heard from them again

I also had an issue in the past where I was advised to contact NI Support by my NI Bascamp handler ( ). Support wouldn't talk to me because I didn't have an SSP. It was only after further intervention by the handler that they got onto it.

We are lucky to have AQ and friends peruse this forum and interact, but customer facing NI systems are set up against them to be effective sometimes. I've probably said this before, or something similar. If you find an excellent applications/sales engineer, get their direct number and hold on to it like a limpet to a rock because you need them to circumvent the systems' barriers.

5 hours ago, rolfk said:

In addition I'm myself not a proponent of installing always the latest and greatest software version if not really necessary. And developing also tools and libraries for reuse it is again not an option to only develop them for the last version. So even if a bug gets fixed I might not profit from that immediately but due to the feeling of being so disconnected anyways it doesn't even feel like it is getting fixed ever.

Considering there are known bugs going back to 8.x that still aren't fixed (last time I looked), this is my view too. Even so. It's not good enough to "fix bugs". I need my bug fixed, even if I'm the only one reporting it. That is why I'm leaning more and more to open source solutions because if they won't fix my bug, I will - and I don't care what language it is written in

 

 

 

 

 

Edited October 30, 2017 by ShaunR