LabVIEW 2017 Editing Issues

[Neil Pate]

I am just getting started with LV2017 on a new project, and have found some horrrible IDE "improvements" that are messing around with my work-flow.

The first one is auto-wiring when you drag code into a stucture (as discussed here).

My latest gripe is strange behaviour when dragging a VI from one BD window to another. I do this operation quite a bit to copy code. In LV2017 now when I drag a VI in from another VI as soon as it enters the new VI (but before I have released the mouse) it is as if the block diagram of the target VI only refreshes like once a second and so I see my VI jerk around. It does this the primitives as well as other VIs.

I cannot comment about LV2016, but at least in LV2015 and every other version I can remember, dragging a VI from one block diagram to another was butter smooth.

Anybody else seen this or is it just me?

Edited September 25, 2017 by Neil Pate

[Rolf Kalbermatter]

I'm not sure it is the same as in LabVIEW 2016 but they changed quite a bit about how the moving (and ctrl-dragging) of objects works. When at first confronted with this it felt smooth and actually quite impressive. That is until I had to work on a larger project in LabVIEW 2016. Suddenly everything started to get quite jerky and I ended up frequently to involuntarily dropping things somewhere on the diagram where I never had intended to do it, simply because somewhere along the jerkyness LabVIEW decided that I had released the mouse button or something.

To me it feels like a nice idea that got executed based on a limited test but not quite tested on real world professional sized projects. Or every developer at NI uses only the highest end super powered machines with CPUs that normal money can't buy you .

 

Edited September 25, 2017 by rolfk

[LogMAN]

If you compare LV2017 to LV2015 you'll notice that LV2015 only shows the outline of the contents, while LV2017 renders the whole thing. And not only does LV2017 render the whole thing, but it also shows broken wires while dragging, which means it compiles the code, which is obviously time consuming. And for some reason it does that every time the cursor moves

Edit:

• I just noticed that LV2017 also moves FP objects while dragging said code on the BD
• Try moving the cursor very slowly, it renders much more smoothly. It actually doesn't render while the cursor is moving faster than a certain speed.

Edited September 25, 2017 by LogMAN

[smithd]

24 minutes ago, rolfk said:

To me it feels like a nice idea that got executed based on a limited test but not quite tested on real world professional sized projects. Or every developer at NI uses only the highest end super powered machines with CPUs that normal money can't buy you 

One of these sounds more like NI than the other 

Edited September 25, 2017 by smithd

[Neil Pate]

I am pretty sure I saw somewhere on the darkside (perhaps in the beta discussion) there is a LabVIEW.ini key to turn all this "goodness" off. I cannot find the thread now that I need it.

[LogMAN]

1 hour ago, Neil Pate said:

there is a LabVIEW.ini key to turn all this "goodness" off

Here you go: https://forums.ni.com/t5/LabVIEW/Labview-2016-new-improvments-to-selecting-moving-and-resizing/m-p/3337796#M979928

[Neil Pate]

24 minutes ago, LogMAN said:

Here you go: https://forums.ni.com/t5/LabVIEW/Labview-2016-new-improvments-to-selecting-moving-and-resizing/m-p/3337796#M979928

Thanks, that partially solved my problems. Dragging in from a different VI works properly now.

Still cannot turn off that stupid grey filled selection box which is so sluggish.

[crossrulz]

There were several improvements that were made due to the Champions griping enough and actually got some R&D ears.  I do not remember if those made it into 2017 or if they were pushed to SP1.

 

The new feature in 2017 that annoys me is the autowiring when you drag code into an out of a structure.  You can turn that off by pressing W during the drag.

[Neil Pate]

Doesn't seem to have made it into plain 2017. Not sure when SP1 is coming out as now they have moved the release dates around. Perhaps before the end of the year?

Not really sure how stuff like this makes it into production. I have a *beast* of a dev machine and am working with a tiny block diagram at the moment but still the grey selection colouring feels so sluggis

[hooovahh]

There isn't a release date for SP1, but I'd suspect (with no inside information) I'd guess November-ish due to that being 6 months after 2017 release.  I must not drag from one BD to the other very often because I didn't know this was an issue.  With two relatively simple VIs dragging around works fine and is pretty responsive.  But as soon as I try with a project that has actual code in it I see the 1Hz refresh you are talking about.  I did however find an INI key you might be interested in which reverts some of the 2016 live drag functionality.

If you add LiveDrag=False to you LabVIEW.ini you lose the live drag functionality, but I also found that dragging from one BD to another seems to be improved as a result.  

EDIT:  Or pressing 'x' mid drag to disable it for that drag seems to help.

[Neil Pate]

Yup, that is the key LogMAN referred to in his post. Switching off auto-wiring also fixes the problem.

That is the one problem with the beta, I always run it in a VM, so issues like this I assume are just because the VM is getting in the way.

[hooovahh]

Dang and I thought I read every post clearly.  Anyway I can't talk about the beta, and if a thing appears fixed in the beta or not, but I think I can say that I made NI aware of this in the beta forum.  If a CAR is assigned I'll post it here.

[Neil Pate]

Bump for LV2018, no noticeable improvement in this new behaviour that I can see. Editing still feels sluggish and now I am running directly on my dev PC. I have turned off LiveDrag, but wiring operations (especially selections) just seem sluggish.

Anybody else troubled by things like this? 

[smithd]

5 hours ago, Neil Pate said:

Bump for LV2018, no noticeable improvement in this new behaviour that I can see. Editing still feels sluggish and now I am running directly on my dev PC. I have turned off LiveDrag, but wiring operations (especially selections) just seem sluggish.

They're trying to ease you into nxg 

 

To give a real answer: I didn't notice anything different in 2018, but my main version is 2017.1

[Neil Pate]

My main version is 2015, there is quite a noticeable difference. 

Part of me thinks your suspicion about NXG is not entirely wrong!

[LogMAN]

21 hours ago, Neil Pate said:

Anybody else troubled by things like this?

Absolutely. We still use LV2015 for our projects, even though newer version are "superior" in some aspects. Still wondering if there is anyone at NI actually using LV/NXG for real-world applications nowadays. From my perspective, design has become much higher priority in newer versions than responsiveness did in the past. My dev machine is equipped with decent hardware and still LV2017+ and NXG feel slow. The kind of slow where you wait for some freaking animation to finish, not the kind of slow where the code runs slower...

It has gotten to a point where we are frustrated enough to consider moving away from LV, especially for more common tasks that can easily be done in text languages. In the past we implemented those tasks in LV mostly for convenience (only one language to maintain), but maintenance has become more and more tedious and very frustrating in newer versions (don't even get me started on NXG, it's a disaster). I really hope NI takes a hint and allows disabling all the "cute" features in LV and NXG. LV2020 is likely the last version we'll consider for internal testing. Hopefully with positive results or my keyboard will get much more busy than my mouse.

16 hours ago, smithd said:

They're trying to ease you into nxg

Says a lot about it, doesn't it

[smithd]

6 hours ago, LogMAN said:

 I really hope NI takes a hint and allows disabling all the "cute" features in LV and NXG. LV2020 is likely the last version we'll consider for internal testing. Hopefully with positive results or my keyboard will get much more busy than my mouse.

Maybe by 2020 they'll add some nxg-style slide-out palette animations 

[LogMAN]

How about a fade animation for switching between FP and BD?

Or slowly connecting wires with some sparkling effect at its current position?

By 2020 Hollywood will use LV for the next generation of CGI, just wait for it

[hooovahh]

So my experience has been a bit better, but I totally agree with the comments made here.  Our projects were in 2015 and things seemed good enough.  2016 came around and I tried upgrading only to find IDE performance and was terrible, with extremely long load times, seemingly unnecessary hour glass, and a Save All that would take about 20 seconds per VI.  I reverted to 2015 and told NI about my experience and shared my project.  2017 came out, and it was a bit better so we started migrating projects to it.  Upgraded to SP1 as soon as we could.  It still wasn't at the 2015 level but I just needed me some VIMs.  2018 came out and I've been thrilled compared to 2016 and 2017.  It is hard to say if it is at that 2015 level but in some respects I think it is better.  Especially when switching between contexts of different target types.  This used to take upwards of 30 minutes to go from a project with one target type, to a project of a different type.  Now it is maybe 5 minutes, for this somewhat large project with lots of shared components.  I think the main thing NI had to say that was improved, was the checks on if a thing needed to be compiled.  In many cases this check to see if things needed to be compiled can be recursive, and waste lots of time when it should be clear to a human that it isn't effected.  They tweaked things to make shortcuts in this check that greatly reduced this in some cases like mine.

I'm always surprised to think back and how personally this issue has always been there.  Trying to use the latest version of LabVIEW has always felt slow to me compared to the previous couple years.  I very vividly remember working in 2011 thinking how terribly slow it was compared to 2009, or 8.6, and how editing code was frustrating.  Then a few years later I remember using 2013 and when I would go back to 2011 things felt so much snappier and easier to use.  And even further with using 8.0 and 8.20 verses 7.1.  It is possible that this is just a sign of computers catching up in performance, and these couple year old versions were made for slower machines.

[shoneill]

I recently tried out 2018 having worked with 2015 for the last few years.  I liked the performance (even in a VM). I would be happy to migrate.

Especially FPGA simulation has gotten a lot more stable. We have been unable to simulate our actual FPGA code in 2015 (spitting out random "something went wrong" errors about contacting NI with no particularly useful extra information -ugh-) for a while now, but works a charm in 2018.

 

Ps especially since I'm using "unofficial" vims, the official support for those is a great boon of course.

Edited July 31, 2018 by shoneill

[Jon S]

Hey Everyone,

I was pointed to this thread by a colleague and wanted to answer some of the questions that were posed as well as gather more specific feedback on some of the things that were asked.

First off, we do have engineers at National Instruments that are using LabVIEW for real world-applications. Our Systems Engineers and Applications Engineering Specialists work on some of our largest customer applications. They specifically create and work on real-world code. For LabVIEW NXG, we have a LabVIEW Lead User team that has met with a number of customers and converted their applications to NXG. Their team goal is to provide feedback to the NXG development teams and Product Owners to help us prioritize what we need to be working on.

While a lot of my recent focus has been on LabVIEW NXG, I did want to follow up with the comments about the dragging performance of the LabVIEW IDE first brought up by Neil. I spoke with the developer of live drag about the behavior you are seeing as well as did some testing of it. The behavior you are describing when dragging objects across diagram boundaries (e.g. the drawing delay when dragging from outside a loop to inside) is actually intentional. It was a compromise designed in to help performance when dragging very large selections. The intended user interaction is that if the user really wants to see what the code would look like before releasing the objects, they could stop moving the mouse cursor. If we don't detect movement, LabVIEW will redraw the code. However, it seems this is being inferred is that there is sluggish behavior when moving things between diagrams. If you drag across diagrams and immediate release are you seeing a delay in moving the code? Your comment about seeing the same behavior when moving a single primitive makes me suspect that we aren't struggling to keep up from a performance stand point, rather the UX that we designed is not having the desired effect. Worse off, it sounds like it's having a negitive effect.

As an aside, we don't need to do a full compile when we are doing live drag. Type propagation is just the part of compile that determines wire and node data types. When we are doing live drag, this is the only part of the compilation process that we have to do.

Thanks for the feedback everyone. I know there were some other generic performance issues that were mentioned, and I don't want to give the impression that I'm ignoring them. I just wanted to focus on the issue presented by Neil first.

Jon S
LabVIEW NXG Product Owner

[hooovahh]

So I think part of the reason I hear people say the same thing of "Does anyone at NI even use LabVIEW for real projects?" is because every decently sized project I've worked on has these same types of issues.  And it sounds like other users are in the same boat in some sense. 

If every real project you used LabVIEW on had huge compile time issues, builds that fail 3/4 of the time, constantly needing to delete compile cache to build, long load times when switching contexts, slow drag and drop, long save operations, and other IDE usability issues, then asking "Does anyone at NI even use LabVIEW for real projects?" starts to be a valid question.  There certainly has been times when using NXG that I've thrown my hands up, and wonder why someone at NI didn't notice a glaringly missing feature, or a usability issue.  Things that I'd hope any real developer would notice.  With NXG there is at least the valid excuse that NI is prioritizing features.  Sometimes I wish I could just have someone from NI follow me around all day and see the issues I have which aren't show stopping, but annoying enough to hinder development.

[Benoit]

I wish so much to be in direct contact with NI team development... Or be part of the team that addresses the issues. there is some that are in the bug list since over 8 years and the work around is do not use LabVIEW use something else to do it... like .net issues per examples.

Is someone talk to them about Agile development?

Sometime new feature need to be postpone in order to fix the old sh*t that are blocking point.

Looks like the marketing has to much power.

Please be stable then add new feature that people ask... not the one that just look great and kill the CPU... 

Just some though...

Benoit

 

[Neil Pate]

Hi Jon,

Thanks for your comments. It is nice to know our concerns are being taken seriously. I attempted to create a video of the behaviour I originally posted about, but cannot recreate it at the moment. I have just tested 2013, 15, 17 and 18 and all drag operations seem quite smooth (LiveDrag=False in my LabVIEW.ini file for '17 and '18), but these are for very simple test VIs not in a project.

I have definitely seen the issue in '18 in the last month or so though. I currently use '15 for all serious projects and only tinker with '18 for personal projects. 

The grey selection rectangle introduced after 2015 does feel a bit sluggish though.

One thing I did notice in my comparison tests is that the toolbar seems to refresh much more often in '17 and '18. Try this experiment: create a VI and drop down a single For Loop. Now resize this loop and take a look at the toolbar. In '13 and '15 nothing noticeable changes in the toolbar however in '17 and '18 the toolbar seems to refresh/redraw (flickers) regularly.

If I see the other issues again I will try and take a video of it in action.

2018-08-28 23-26-24.flv

[smithd]

21 hours ago, Benoit said:

I wish so much to be in direct contact with NI team development... Or be part of the team that addresses the issues. there is some that are in the bug list since over 8 years and the work around is do not use LabVIEW use something else to do it... like .net issues per examples.

One thing I absolutely wish is that NI would have a publicly facing issue tracker.

For example, the jira for jira: https://jira.atlassian.com/projects/JRASERVER/issues/JRASERVER-67872?filter=allopenissues

or the bugzilla for mozilla: https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Firefox&content=crash&comments=0

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. Or, another way, make an idea exchange for bugs. If something hasn't been fixed in 8 years it means that people thought it was too hard to fix  or that not enough people are effected or some other combination of factors -- being able to locate bugs and see the workaround or press a button to say "this affects me too!" would make their decisions significantly less noisy, it seems to me.

21 hours ago, Benoit said:

Looks like the marketing has to much power.

Much of marketing's purpose in life is to take feedback from customers & sales, market research, business needs, etc and make strong recommendations on how to capture more and more desirable customers. I think a more accurate statement would be that you think marketing is wrong...and as an engineer, the belief that "marketing is wrong" is kind of a given