LabVIEW 2017 Editing Issues

[hooovahh]

I've heard the NI argument against older issues -- there may be internal or customer-specific information, but I don't see that as an excuse moving forward.

I haven't heard that argument but I think it is a good one.  Often times I will see some odd behavior in a larger application, and then start pruning it until it is small enough to send to NI.  It often has a weird unpredictable behavior, and contains some amount of the original application.  I will send the minimized program to NI with instructions on how to reproduce it and what the observed behavior is.  From my point of view I can't say "Memory allocation when using DVRs in a reentrant inlined VI set to subroutine, causes a race condition with an IPE structure if the moon is out."  I just have weird behavior and send it to NI.  They have a bug tracking system but I assume my whole project goes along with the issue and my instructions.  I'm not sure how easily NI could expose the issue to the world to vote one, or view, without including my application.  And even if they did it might not always be clear that an issue I'm having is the same as someone else's.  I think a publicly tracked issue tracker is a good idea, and I'd like having it, I'm just saying I can see why NI doesn't do it.  Issues with JIRA, and a web browser won't contain 5,000 individual files of source code to reproduce the issue.

[smithd]

Yeah I suppose splitting it up theres three sorts

• Obvious issues: things you can get down to a simple test case, or easily describe (eg when I use quickdrop to insert delete from array onto a wire, it isn't correctly wired)
• Crashes: They already have NIER. It would be interesting to see how common a crash you just got is, but at least they know (for the x% of labview instances that are on a network and not firewall blocked).
• Wtfs: This is what you described, generally one-off issues

And of course I have no clue what proportion of issues fall into which bucket. Take crashes, for example-- I wouldn't guess the total quantity of distinct crash types is all that high. So if thats true, are there more clear-cut issues or wtfs out there?

Edited August 31, 2018 by smithd

[Jon S]

Thanks for the video Nate. I'm seeing if we can get some more info about what is causing that flickering behavior. I did test it out and it looks like it was introduced in LabVIEW 2016.

I'm not sure how many on here are aware, but we've recently went through a re-org within application software here at National Instruments. Along with creating vertical teams with full stack knowledge, one of the biggest things we've done is create the role of Product Owner within R&D. This role takes on a lot of the responsibilities of an Agile product owner. It is our product owners' responsibility to understand our users and prioritize features based on their needs. Our marketing department will help identify target personas and market areas, but the product owners are setting priorities as well as signing off on features before they make it into the product. We are changing the way we do development to release higher quality features, create more useful features and validate the features actual solve the customers' problems.

I'm know many here are familiar with the LabVIEW Known Issues list which is our mechanism for bug tracking. It's not interactive like many of the options that are listed so I do realize that it doesn't solve all of the problems described. When you do send code or applications that reproduce your issues to our Applications Engineers, one of the things that they try and do is narrow down the issue so that it is more easiliy reproducible. If not, we typically try to reproduce on a VM so that it limits the setup time for the subsequent developers that will look into these issues.

I wanted to give you an idea about some of the recent changes we've made to provide more value to our users. The feedback you've provided is good for us to hear and does make a difference.

[Benoit]

Dear Jon,

You were talking about the bug tracking. In deed, it would be very helpful for us, developers that makes promises to our boss and customer, to know when the bug are planned to be resolved. Per example the bug  493662  concerning the .net is causing problem to a lot of us. Listing a work around to use external .dll is a killer for LabVIEW reputation. and this bug is there since 2014... I personally believe that new features should be delayed till all the bug are fixed. All LabVIEW developer will be so happy to not encounter bugs that kills their planning.

So please fight fur us and represent us in front of NI to push them the importance to release a version of LabVIEW without bug.

 

Benoit

[Jon S]

I got some more information on the flickering. It is caused when we do a redraw of the canvas. If you slow down the video of LabVIEW 2015 and before you can actually see the flicker once, when we redraw the canvas. We introduced live redraw in 2016 which makes the flicker obvious because it happens multiple times. I did file CAR 713251 for this which one of my colleagues will prioritize among the other work his teams have on their backlog.

 

With respect to the CAR 493662, I agree that the workaround isn't great. It's only an option if you are both the author and consumer of the .NET Assembly. If you are just using an assembly installed on the system, you can't call the other constructor. This doesn't help your situation, but I have a team that is currently working on .NET for NXG and I did make this an acceptance criteria of their work. I verified in a beta build of NXG 3.0 that we are able to call both of the overloaded constructors.

Quote

 I personally believe that new features should be delayed till all the bug are fixed.

This is similar to the model we are moving toward. The Product Owners have the final say of when we toggle on a feature. It's our role to hold the line for quality and workflow completeness when it comes to turning on features. Hopefully our change in process is noticeable as we move forward.

 

Thanks again for the candid feedback here. It does help myself and other POs have a better grasp on the heartbeat of the community.

[Rolf Kalbermatter]

On 9/9/2018 at 9:26 PM, Benoit said:

Dear Jon,

I personally believe that new features should be delayed till all the bug are fixed.

Realistically that might mean that there is no new LabVIEW feature in many years! So I doubt that this rigorous specification is ever reasonably considered.

[Neil Pate]

I cannot seem to get this to work on 2017 SP1 (64-bit).

Tried various combinations of these:

DragAutoWire=False
LiveDrag=False

But nothing seems to help the editing experience which lags so badly when doing "complicated" operations like a a box selection 😞

This is on a brand new dev PC with 32 GB of RAM, very fast SSD and processor.

[LogMAN]

Are you working on a notebook by any chance?

In my experience LV2016 and LV2017 (never tested SP1 though) get stupidly slow if the graphics card is not powerful enough to render the selection box. Notebooks in particular use CPU integrated graphics and only utilize the "real" GPU if a program requires more demanding 3D capabilities. LabVIEW doesn't fall under that category (yet).

For the few test projects we do in LV2017 we use a sufficiently overpowered machine that can handle virtually anything you throw at it (designed to rendering 3D images from one of our cameras). It's ridiculous. Still not sure what to make of it...

[Neil Pate]

Definitely not a notebook. It is a two week old PC, the fastest thing I have ever used. 32 GB of DDR4 RAM, Xeon CPU, extremely fast SSD and a good GPU.

LabVIEW struggles to draw the grey selection box around stuff; it is actually a bit embarrasing.  If I open a new VI and draw the selection box around a single structure it is "ok" but still quite sluggish. Trying to edit anything sensible leaves me with a slide-show for any editing operations that cause stuff to be redrawn. I have now turned off all options like auto wiring etc and its a bit better, but it is 2019 now. Editing operations in an IDE should not feel slow.

[LogMAN]

That is very unfortunate. NI really needs to work on that.

For reference, I found a complex VI here and used that on my private notebook (decent hardware, enough for LV2015). This is what it looks like on my end (using LV2017.0f2).

It's a bit faster without recording of course, but not much. Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs.

Anyway, it seems that the dragging operation in LV2017 is not a O(1) operation. More like O(n) where n is the number of objects on the block diagram. They probably check every object during the drag operation to figure out which one to highlight.

Works better on the front panel but that is probably because there are less objects on the FP (i.e. no wires).

Edited February 1, 2019 by LogMAN

[Neil Pate]

LogMAN that looks a lot like what I see on my PC, thanks for confirming. As you say, how can this stuff even make it out the door?

ITS A SELECTION BOX, HOW CAN THIS BE SLOW. WHAT IS LABVIEW DOING??? 🤮

NI STOP MESSING WITH LABVIEW. ARE YOU TRYING TO GET US TO LEAVE THE PLATFORM?

Edited February 1, 2019 by Neil Pate

[LogMAN]

1 minute ago, Neil Pate said:

As you say, how can this stuff even make it out the door?

😁

[Neil Pate]

Please don't give them any ideas...🤦‍♂️

[hooovahh]

I noticed some of your VIs were missing and showing a placeholder icon.  I'm guessing as selections are made or scrolling happens, NI is constantly checking for things and the larger the VI the larger the delay, but also the more things it needs to check which are missing the longer the delay.  Of course NI could optimize it and they likely have for most cases, but what you are seeing is probably an issue they didn't test for, or tested for but not in as extreme case as yours.  This is all of course just a guess, but it is based on other IDE performance issues I've seen in the past relating to NI checking for what things need to be recompiled and what things don't.  If you can send the VI to NI I'm sure they would appreciate it, and by extension the rest of us who happen to have to deal with that too.

[LogMAN]

I can present less complex VIs with the same behavior, more or less intense. @Neil Pate likely also doesn't use broken VIs for real world applications and gets similar behavior. The VI in my video is certainly an extreme case that is not fit to be part of any code base, but it serves as a good example for how bad things can get. I don't expect that VI to work flawlessly, but it wouldn't hurt trying to achieve that, even if that means disabling fancy stuff for more complex VIs.

Here is the same VI in LV2015 for reference. To be fair, scrolling is as slow as in LV2017 (or vice versa), but the selection box is so much better.

The VIs I'm normally working with are much smaller than this one. Most of them fit on the screen, so scrolling is not an issue for me. The selection box, however, is a different story and part of my daily work. It being slow is a red flag.

[Neil Pate]

As a consultant I have to work with whatever code my customer has developed. Some of it does indeed take several monitors to scroll across and I just have to deal with this. The IDE should not choke or do "stuff" constantly while I am editing. Also, as is pretty common during development my code spends a lot of time broken as I develop or refactor stuff, and I have to deal with missing VIs all the time as I integrate other team members code back into the main branch.

As LogMAN pointed out, the behaviour of the selection rectangle is so much quicker in 2015 (at the expense of the "amazing must have could not live without" feature of shading the contents of the rectangle). I bet ShaunR is having a quiet chuckle about this whole thing as he gets to use 2012 or something like that.

Sorry if I am coming across angry, but I am. LabVIEW is not exactly a new immature product that is given away for free. We really should not put up with this rubbish. If I have to wait for my IDE to draw a shaded rectangle, regardless of the quality of code underneat, something is deeply wrong.

[smithd]

3 hours ago, LogMAN said:

Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs.

This may have already been mentioned, but have you tried changing the compiler complexity threshold? http://zone.ni.com/reference/en-XX/help/371361P-01/lvdialog/miscellaneous_options/#compiler

Its possible its trying to compile while you drag or something, and maybe the drag selector interacts with the UI thread more or something.

[smithd]

Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.

[LogMAN]

6 hours ago, smithd said:

This may have already been mentioned, but have you tried changing the compiler complexity threshold?

The compiler shouldn't be involved as long as no changes are made to the code. In fact, turning it down to 0 (always limit optimizations) had no impact whatsoever (neither in LV2017 nor in LV2015).

On a smaller VI the selection box is more responsive, but the CPU usage is still about 10-15% while resizing the selection box. Tested on an empty VI in LV2017. The same test in LV2015 shows a CPU usage of about 1%.

Results can vary depending on the hardware of course.

5 hours ago, smithd said:

Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.

Not sure if it only happens on reentrant VIs, but very rarely (maybe once per month) LV2015 lags very badly while scrolling the block diagram. It literally renders the diagram line by line over a period of maybe 20-30 seconds. Once it's done, scrolling is as fluent as it should be. I still haven't figured out why that happens. Maybe the UI thread is clogged by the compiler or something. It is also not tied to a particular machine.

[bmoyer]

On 2/1/2019 at 7:59 PM, smithd said:

Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.

I've noticed a lot of slowdowns with LV2017 and LV2018 doesn't seem any better.  Also, I use the NI-IMAQ extensively and NI-IMAQ 2018 is buggy and doesn't seem ready for widespread use.

I've been trying to deal with these massive slowdowns with LabVIEW 2017 for over a year now and it has really slowed down development for me.  I too have issues scrolling (I have the same 2Hz refresh rates sometimes, but then it seems to mysteriously go away), slow window drags, slow selection dragging, etc. and have contacted NI technical support about this but since I can't provide my project, haven't gotten far at determining cause or solutions.

Why does it seem that nobody at NI is concerned about this behavior?

[LogMAN]

48 minutes ago, bmoyer said:

Why does it seem that nobody at NI is concerned about this behavior?

NXG

51 minutes ago, bmoyer said:

but since I can't provide my project, haven't gotten far at determining cause or solutions.

Send them this VI for reference: https://forums.ni.com/t5/LabVIEW/Very-complicated-labview-block-diagram/td-p/3187507

It may be broken and surely doesn't win a price for simplicity, but it makes the issue clearly visible to anyone.

Now that I think about it, does the Example Finder ship with a decently complicated VI or project to show this issue? That would be hilarious.

I really hope they fix it in LV2019 (fingers crossed🤞).

[Darren]

2 hours ago, LogMAN said:

Send them this VI for reference: https://forums.ni.com/t5/LabVIEW/Very-complicated-labview-block-diagram/td-p/3187507

(standard disclaimer, unreleased software, not an official benchmark, etc. etc.)

I just tested dragging selection boxes on that diagram in LabVIEW 2018 and in the latest LabVIEW 2019 build. Selection rectangles draw significantly faster in 2019. Window scrolling while dragging a selection box is also much faster.

For reference, my dev machine is Win7-64, 16 GB RAM, E5-1650 3.5GHz.

[LogMAN]

That is good news. Thanks for sharing, Darren!

21 minutes ago, Darren said:

Selection rectangles draw significantly faster in 2019. Window scrolling while dragging a selection box is also much faster.

For reference, my dev machine is Win7-64, 16 GB RAM, E5-1650 3.5GHz. 

Your hardware sounds reasonable. By significantly faster do you mean "fluently" or "stuttering, but not as much as before"?

I'm so ready to replace LV2015 and finally get my hands on malleable VIs (not to mention all the other features that were added). Can't wait to finally try out LV2019.

[Darren]

2 hours ago, LogMAN said:

By significantly faster do you mean "fluently" or "stuttering, but not as much as before"?

Here's a GIF comparing the selection drag + scroll speed on the same large VI in 2018 and the latest 2019 build, both on my dev machine.

[LogMAN]

Wow, thanks again for sharing! That is so much better, it might actually work for me.

Now I'm even more excited for LV2019 😍