Problems with LabVIEW 2017?

[drjdpowell]

What problems have people been having with LabVIEW 2017.   I currently have the problem that it freezes on trying to open any project (including creating a fresh one).  This is the second serious issue I've had (after this).  

[ensegre]

Immediate crash "Fatal Internal Error 0x00000001 :  "VariableManager.cpp", line 85" opening on linux VIs with controls bound to shared variables (project created in Windows). Something must be going on with the compiled cache, because eventually I can open the VIs (binding reset to none) at third attempt after two crashes.

 

[crossrulz]

The only real issue I have had with 2017 was The distribute object tools often crashes LabVIEW 2017

[hooovahh]

Same as crossrulz.  But the one brought to my attention recently scares me, and that is not being able to build an executable in some situations, when using VIMs.  Since I'm in the middle of a major overhaul of VIMs in our reuse library any given application will likely use 10s of VIMs, in 100s of instances.  And debugging when one VIM prevents a build from happening would be a major pain.

[drjdpowell]

56 minutes ago, hooovahh said:

Same as crossrulz.  But the one brought to my attention recently scares me, and that is not being able to build an executable in some situations, when using VIMs.  Since I'm in the middle of a major overhaul of VIMs in our reuse library any given application will likely use 10s of VIMs, in 100s of instances.  And debugging when one VIM prevents a build from happening would be a major pain.

A Windows Restore revision fixed my initial issue, whatever it was.   Then I got to work debugging a second issue in building, which turned out to be the very VIM issue you are talking about.   I was able to identify a workaround (posted in your link), which is to delete the "Help path" to the extended documentation.  If your VIM don't have extended documentation, then I think you are OK. 

The bug involves VIMs, extended help, and at least one other issue that I could not identify (builds of simple exes don't exhibit the issue).

Edited October 11, 2017 by drjdpowell

[MarkCG]

I've been experiencing a lot of crashes with 2017, way more than with 2014 which is what I was using before. Why or how they are caused I can't say. 

[G-CODE]

I've been encountering so much strange behavior in the 2017 dev environment that I started taking screenshots of all the weird stuff I was seeing and I finally just gave up.

I already mentioned the weird stuff with parallel access DVRs, but I keep getting some non-parallel DVRs where the wire in the DVR in place element structure is just broken for no reason. Reattaching seems to fix it for a while.

One screenshot I did keep was an error state that occurred from a class appearing as a duplicate within a Typedefs folder (attached). Don't ask me how that happened. How can a class exist in two places? It certainly didn't exist in two places on disk and definitely didn't exist in the typdefs folder.

Oh, and if 2017 seems to be eating up processor usage, but you have NO processes running and everything is just sitting there idle, try closing the breakpoint manager window if you have it open. That worked for me.

Like I said, this is just a partial list...

[Neil Pate]

I have given up on 2017 and moving development back to 2015 SP1. I don't need channels, wouldn't mind VIMs but it is not worth the tradeoff.

Part of me suspects this is a push to annoy old-timers enough to try out NXG (which I suspect will be ready for prime time no earlier than 2019).

[infinitenothing]

I noticed no significant change in bugginess. I'm 100% developing in 2017, mostly targeting cRIO developing on Win10

Edited October 11, 2017 by infinitenothing

[MarkCG]

Do you guys think that sending the automated error report to NI after a hard crash actually helps them fix things ? I usually click no out of instinct but may be I should start. It's hard to believe how much we put up with LV's hard crashes-- for me a couple a day is no big deal. But otherwise they seem pretty rare in other programs nowadays. Chalk it up to the crustiness of the codebase I guess. 

[crossrulz]

29 minutes ago, MarkCG said:

Do you guys think that sending the automated error report to NI after a hard crash actually helps them fix things ?

AristosQueue swears that they are useful.  He mentions it in almost every event I have seen him at.

[Aristos Queue]

2 hours ago, crossrulz said:

AristosQueue swears that they are useful.  He mentions it in almost every event I have seen him at.

As a matter of fact, I fixed a crash yesterday as a result of accumulated NIER reports. If we get enough stack crawls, sometimes we can triangulate these impossible-to-reproduce crashes. Sometimes even a single stack crawl is enough, as it lets us desk-check that code and imagine, "what if X happened? what if Y happened?" It's tedious, but, yes, it does help. If nothing else, it let's us flag a given code path and we can add more debugging logic along the route so that the *next* time someone crashes, it includes more information in the crash log. Eventually, we can trap these things.

@MarkCG Please do send in the NIER reports. And -- I know this is more controversial -- please enable the Customer Experience feedback. If you're in a high-security industry, I understand, but for everyone else, the usage data about what features you're using really does guide priorities, both for new features and for fixing CARs. It does help.

 

[Aristos Queue]

On 10/11/2017 at 9:57 AM, MarkCG said:

I've been experiencing a lot of crashes with 2017, way more than with 2014 which is what I was using before. Why or how they are caused I can't say. 

This, by the way, is why NI does not generally advertise version X as being more stable than version Y. I can tell from bug reports coming in that 2017 is way more stable than 2015, especially when I filter for CARs filed specifically against new features, but all it takes is one bug that happens to be in a user's personal common code path for them to see it as massively unstable.

[Aristos Queue]

23 hours ago, planet581g said:

Oh, and if 2017 seems to be eating up processor usage, but you have NO processes running and everything is just sitting there idle, try closing the breakpoint manager window if you have it open. That worked for me.

Surely that isn't unique to 2017... the breakpoint manager hasn't changed (to the best of my knowledge) at all in several versions.

Are you sure that is a new issue? (Not that I'm saying that the Breakpoint Manager *should* be eating CPU at all, but if it is the cause, I would expect it to go back at least to 2015 and probably to 2013.)

[infinitenothing]

Is there a way to check if we're in the customer experience feedback program?

[smithd]

1 hour ago, Aristos Queue said:

Surely that isn't unique to 2017... the breakpoint manager hasn't changed (to the best of my knowledge) at all in several versions.

Are you sure that is a new issue? 

I've seen the high cpu issue for years, and never use breakpoint manager. Actually the high CPU load issue is kind of a good sign, as its usually after labview has been open for a long time, which means it hasn't crashed yet.

 

Personally I haven't seen anything with 2017 which makes me think its less stable, but I don't use it as regularly as I use 2015. The thing that has me annoyed is that after installing the new driver set max crashes on every single close (in addition to the regular max crashes).

Edited October 12, 2017 by smithd

[G-CODE]

23 hours ago, Aristos Queue said:

Surely that isn't unique to 2017... the breakpoint manager hasn't changed (to the best of my knowledge) at all in several versions.

Are you sure that is a new issue? (Not that I'm saying that the Breakpoint Manager *should* be eating CPU at all, but if it is the cause, I would expect it to go back at least to 2015 and probably to 2013.)

It might exist in 2015 as well? I realize if we can't make these issues reproducible then it's difficult to report.

I'm going back and forth between two projects right now - one uses LV2015 and the other uses LV2017 - so I'm forming opinions about the apparent stability of each.

The LV2015 project is YUGE!!! and it's mostly stable as long as I don't right-click on anything in the project Dependencies folder and select 'Why is this item in Dependencies?' which will instantly crash LV. The safer bet is to right-click an item and select 'Find>Callers'. So one of my few gripes with 2015 is I've seen some really strange dependency issues that have been difficult to track down because there are no typedefs, globals, etc. in these classes that would cause dependencies to exist.

The LV2017 project only has about 50 classes so far, but the latest issue I'm experiencing isn't hard crashes, but the project getting stuck with a spinning wheel indicating it is working, but it just never comes around and I have to force quit the application. It seems to happen as soon as I right-click a class to save it after I've added some methods. I'll give it 3-5 minutes in hopes that it will finish whatever it is doing, but every time I eventually have to force quit and restart LV.

[Aristos Queue]

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. Please, for your own sanity, take a moment to report those things. It's the only way we'll know about them and possibly fix them. I know it is a pain to pack up your code and get it into a service request, but posting about it on LAVA doesn't help! :-)  (Ok, I admit... it does help sometimes when you happen to catch attention from someone at NI and it is something concrete to report, but a hang caused by "something" in a large hierarchy isn't one of those!)

Are you using malleable VIs? There's one infinite compile in 2017 that we found recently that I've fixed in the upcoming 2017 SP1 release, but that's the only one I know of like what you're describing.

[Aristos Queue]

On 10/12/2017 at 2:53 PM, infinitenothing said:

Is there a way to check if we're in the customer experience feedback program?

Details of the CEIP program are here: https://www.ni.com/pdf/legal/us/CEIP.pdf

The answer to your question is here: “…navigate from the Windows Start Menu to All Programs » National Instruments » Customer Experience Improvement Program.”

You should also be prompted the first time you run a fresh install of LabVIEW (assuming you don't copy in an existing config file).

[ShaunR]

18 hours ago, Aristos Queue said:

I'm not sure why so few people escalate those sorts of issues to us,

Because the release time-frame for bug fixes and LabVIEW itself doesn't help with the project at hand and it may quite possibly be rolled up into a new LabVIEW release requiring a new purchase. So people ask some questions on the forums, find a work around and move on. We are working on weekly timescales and NI is 6 monthly. We need to resolve bugs within days, not months. A bug fix in 6 months time might as well be never, especially if we have to buy a new LabVIEW version  to get it.

[Aristos Queue]

51 minutes ago, ShaunR said:

Because the release time-frame for bug fixes and LabVIEW itself doesn't help with the project at hand and it may quite possibly be rolled up into a new LabVIEW release requiring a new purchase. So people ask some questions on the forums, find a work around and move on. We are working on weekly timescales and NI is 6 monthly. We need to resolve bugs within days, not months. A bug fix in 6 months time might as well be never, especially if we have to buy a new LabVIEW version  to get it.

I'd buy that argument except that

a) a lot of you do buy the next version

b) I take the time to report bugs against Visual Studio and MS Windows and lots of other software so that eventually those issues get out of my way

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. :-) 

[ShaunR]

1 hour ago, Aristos Queue said:

I'd buy that argument except that

a) a lot of you do buy the next version

b) I take the time to report bugs against Visual Studio and MS Windows and lots of other software so that eventually those issues get out of my way

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. :-) 

You have all that time? They are not working you hard enough

• Minor Updates ship roughly every six weeks. These updates may include new features, bug fixes, and changes needed to reflect platform changes (e.g. changes in Windows). You’ll be able to tell which minor update you’re running by opening the Help, About and reading the second digit of the version number, for example 15.1 or 15.2.
• Servicing Updates are very targeted releases that typically contain bug fixes and ship more quickly. These servicing updates can ship often (e.g. weekly). You’ll be able to tell which servicing update you’re running by opening the Help, About and reading the third string in the version, for example 15.1.x, 15.2.y.

source

Not even the same ball-park, I'm afraid.

 

Here's the thing with a).

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. Requiring customers to buy a new version to fix a bug is, IMO, bordering on predatory.

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. In fact. Unless you have an SSP you can't even get to talk to anyone about bugs as you cannot get past the gate-keepers.

New entrants won't be looking for old bug fixes-they will expect (rightly or wrongly) for it to be bug free and will be seen in these forums when they encounter one as they can't wait 6 months.

Edited October 14, 2017 by ShaunR

[Antoine Chalons]

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

anyone who upgrades before SP1 is out is also insane

people do that??

[hooovahh]

3 hours ago, Antoine Chalons said:

people do that??

I did this time round...I mean VIMs am I right?...still I'm lucky enough that my project development time was a year, full well knowing SP1 will be out before the deliverable is required, but that still is a decent amount of risk running a new version with so few miles on the tires.

[Aristos Queue]

7 hours ago, Antoine Chalons said:

people do that??

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.