Jump to content

NXG, I am trying to love you but you are making it so difficult


Recommended Posts

1 hour ago, Neil Pate said:

Why can I not easily branch off a wire by clicking on it somewhere? Now I have to right click and select the option to create a wire branch

File > Preferences > Editor > Wiring lets you change this back to CG behavior.

1 hour ago, Neil Pate said:
  • I like the really like the zoom but please let us pan with the middle-mouse or something similar

NXG gives you the hand tool when you hold the space bar instead of Ctrl+Shift like in CG. One minor improvement (my opinion) is that, in NXG, the scroll wheel will move the diagram up and down but if you shift+scroll, the diagram will move right to left (CG just scrolls up/down faster).

That's about the extent of my NXG knowledge.

  • Thanks 1
Link to comment
7 hours ago, jacobson said:

One minor improvement (my opinion) is that, in NXG, the scroll wheel will move the diagram up and down but if you shift+scroll, the diagram will move right to left (CG just scrolls up/down faster).

Would be nice if NXG, like CG, would support the horizontal scroll options available on many mice these days. In NXG that is somehow bound to zoom if the Zoom Control option is set to  "Ctrl + Mouse Wheel"

if Zoom control is set to "Mouse Wheel" the scroll left/right is bound to scrolling up and down, makes no sense.

Link to comment
6 hours ago, smithd said:

This is kind of an interesting concept to me and its one I've been curious about. Just based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor and more the combination of "not a real programming language", python being the thing taught in schools, relatively high costs, limited developers and general unavailability of a great many experienced labview devs outside of a pretty insular community, and the deployment/runtime situation (labview doesn't get a free pass like dotnet, javascript, and in most cases java).

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

Don't forget NI is a hardware sales company. LabVIEW is just the tool that allows them to sell more hardware. I suspect this is why there is such a heavy push to have hardware integration directly in LabVIEW NXG (to the detriment of the system as a whole). NI have decided to get in on the whole cloud business with SystemLink but again they have missed the point that by far the majority of LabVIEW devs just dont care about this or wont use it.

Happily, the community edition will be able to compete on price with all the other zero cost languages out there, but candidly I feel that the ship has sailed for younger devs, and those holding LabVIEW tickets are still at home putting their pyjamas.

Edited by Neil Pate
Link to comment

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

For example, I could previously have multiple enums called "State" in my project because each copy is in a different class/library: ClassA.lvclass:State.ctl and ClassB.lvclass:State.ctl. However, NXG forces globally unique names for enums/clusters.

* I last checked in NXG 3.0 -- perhaps the ability will exist in NXG 5.0?

 

16 hours ago, Neil Pate said:

The GUI is so dull in general. The colours are washed out and grey everywhere is just depressing. It sounds silly but it makes me not want to use it.

I think this trend started a few years ago: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Restore-High-Contrast-Icons/idi-p/3363355

Link to comment
14 hours ago, smithd said:

This is kind of an interesting concept to me and its one I've been curious about. Just based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor and more the combination of "not a real programming language", python being the thing taught in schools, relatively high costs, limited developers and general unavailability of a great many experienced labview devs outside of a pretty insular community, and the deployment/runtime situation (labview doesn't get a free pass like dotnet, javascript, and in most cases java).

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

I remember reading somewhere that the idea behind LabVIEW was to make data acquisition as easy as creating a spreadsheet. That is anyone with some ability to use a computer and understand basic math could create something that worked for their purposes without being a programmer. Gradually more and more complexity and capability was needed and the professional LabVIEW programmer emerged, similar to how professional Excel/VBA programmers arose in the financial industry. 

But like everything the need for the professional LabVIEW programmer was a product of particular historical circumstances, and I think history has moved on. Since many big companies have invested a lot of money in NI hardware we will be some demand for LabVIEW programmers to maintain these system, but it will taper off over the decades. I think it will be like COBOL -- you'll have a few crusty old guys wading into ancient codebases to make fixes and smaller changes but no greenfield development.

I may be wrong but I think NXG is NI's last gasp attempt to stay relevant and that it will fail. The attitude in most companies I have experience with is that "not owning your source code" is a major, major problem, and I don't see that changing. LabVIEW is seen as a sometimes necessary evil only.

If NI wanted LabVIEW to stay relevant for years they would make it open-source, and keep selling hardware and software add-ons for it. But they know their business better than I do and what's good for me isn't necessarily good for them.

 

 

Link to comment
4 hours ago, JKSH said:

For example, I could previously have multiple enums called "State" in my project because each copy is in a different class/library: ClassA.lvclass:State.ctl and ClassB.lvclass:State.ctl. However, NXG forces globally unique names for enums/clusters.

Yikes, this I did not know!

This was probably decided by the same committee that came to the conclusion that nobody really should be using Virtual Folders anyway. 🙄

Link to comment
20 minutes ago, Neil Pate said:

This was probably decided by the same committee that came to the conclusion that nobody really should be using Virtual Folders anyway. 🙄

You mean the same committee that works with Visual Studio all the time? I wonder where they get their ideas...

image.png.b839d49ba2375cbf7a6c0bcb0f929df5.png

5 hours ago, JKSH said:

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

Yes, that is a bummer. Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void). Since classes cannot be nested in LabVIEW CG/NXG, the only way is to put both of them inside a common library.

image.png.30bd7c0a1e42855ad46b52b32a980f25.png

Now, where have I seen this concept before...

Link to comment

I must admit I have not fully grokked all the changes with classes and types in NXG. Last time I looked it was a mess so I just left it for a while.

Your screenshot makes me sad for a bunch of reasons. So much ugly grey except for the totally random bits of blue thrown in.

Now, lets think about the lack of consistency here.

  1. On the top left the file icon has a blue background to show us it is selected, ok cool
  2. So in the tree view Library.gcomp is selected, but it is not blue... ok... why?
  3. The tab in the middle pane is not coloured blue to indicate it is current... ok... why?
  4. On the right we have a tab structure and the Document tab which is currently selected is highlighted...

Sigh... am I the only one who sees stuff like this or am I just crazy and looking at it totally wrongly?

Why are the tickboxes in the middle coloured blue? This is so random.

image.png.2d22254f8ae84831c809e0c094d8946d.png

 

Now, I am not a graphic designer, and I am sure that NI has done their due diligence in designing this GUI that we spend 40+ hours a week interacting with, so I will give them the benefit of the doubt (again...) but I just don't get it.

  • Like 2
Link to comment

Some of my thoughts after working 6 years as 'Labview Developer'

  • Popular languages like python or c# gained so much momentum, entry level is much easier than few years ago, it will get closer to LV entry level
  • LV did not change much over last 6 years, things that I remember were maps, sets, vims and independent runtime engine
  • paid and closed source kills any chances of becoming more popular, in my opinion it is ok to pay but for addons like ML or DSP, if i recall at some point excel addon required payment :)
  • decline in job offers in LV, I ve seen more and more python/.net  in test eng field (at least in Europe)
  • source control is terrible with binary files compared to text diffs & history available in text IDEs
  • cheaper hardware alternatives like Advantech, I would never buy average PXI controller for 8k, when you can get high end workstation + Thunderbolt card + chassis
  • I no longer see LV skills valuable on the market and started to do more text based programming

 

Edited by pawhan11
hundreds of whitelines
Link to comment
20 hours ago, smithd said:

based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.

Link to comment
3 hours ago, LogMAN said:

Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void).

I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been. The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved. Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).

Link to comment

The problem with LabVIEW is, they send you a mug, but they don't make the kool-aid resupply free. And unfixed bugs after 2 decades get old, literally (my mug is fading though, which makes it "NXG", I guess).

The really exciting prospect is all these brand new bugs which will never be fixed, yeah!

Bottom line though, none of my students or colleagues will touch it with a pole if they can avoid it, and NI hardware products can be interfaced with MATLAB and python anyway, so why bother?

Link to comment

@Aristos Queue, the problem is the GUI is everything. It does not really matter what is going on under the hood (although all us CG devs really appreciate the regular strides forward).

I have yet to speak to another dev who has tried out NXG and is really excited about the majority of changes that have been made. It *really* feels as though very few actual current LabVIEW devs were consulted in the process. I am sure you will say that NI have done studies and had focus groups etc etc (which I totally believe), but to me personally the new changes suck.

I have used the Digital Pattern Editor which has the same GUI framework as NXG and the MDI nature of the GUI sucks so much. All the time I need to be able to look at several different things, and MDI makes this an exercise in frustration.

 

  • Like 2
Link to comment
7 hours ago, Aristos Queue said:

I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been.

Yes, the execution system hasn't changed but the appearance did, at least from a users perspective. LabVIEW CG has a clear distinction between the two, which doesn't exist in NXG. Classes and typedefs are both represented by the same kind of object (G Type). Although their abilities and representation is different, they are represented as the same kind of thing. If you take a control in LabVIEW CG and turn it into a class, you choose "Convert Contents of Control into class" and it becomes an entirely new type. In NXG, however, you can simply add class functionality. Now, unless a typedef is a class in secret, there is no way to simply add class functionality without converting it into a class first.

image.png.f0dde12b9a2f9581a15fe09993d288a9.png

Maybe I'm reading too much into it, but this is how it appears to me.

8 hours ago, Aristos Queue said:

Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).

Yes, the amount of types and what they represent didn't change and I understand the technical reasons for how they are implemented, but why use the same file extension? I work with engineers who don't know the difference between a class and a struct (and they don't care).
What I'm afraid will happen is this:

image.png.5aed73ad94c76396c27dbdd0217cada7.png

Here is the same thing in CG

image.png.2eb919010e95cb02df8f4e6b1becee10.png

For all I care, the file contents of a typedef can be equivalent to a class. I don't even mind if a typedef was a class in secret, as long as they are easily distinguishable by the end user (i.e. me). That is currently not the case.

8 hours ago, Aristos Queue said:

The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved.

That is good news. Maybe it was addressed in 5.0, can't wait to try it out. Need to wait for the VM to finish though.

Link to comment

I like the side discussion here. About the future of LabVIEW.

I've been in the field for close to seven years now and I constantly ponder if relying my carrer on LabVIEW is a wise decision. Because I mean, I'm no junior anymore, and just as much as by chance as by choice LabVIEW has become my speciality now, and changing track is harder and harder for each year.

Last year I attended my first NI Week and to judging from NI's marketing it was clear, according to me, that they have moved away from the use case of an engineer/scientist with a benchtop instrument controlled by a Windows PC with LabVIEW. Measuring a voltage or communicate with a IC-circuit or something like that. And I can understand why. That is a solved problem and you can just as easily do it with Python/Arduino/Raspi (everybody knows atleast one scripting language these days).

A lot more focus was on (physically) big system wide solutions, mostly for testing within the semiconductor industry and radio/5G. And I guess that makes sense aswell. These are areas where hardware matter and the price point is still quite high. Perhaps their vision is that you will buy a full solution from NI in the future and only use the GUI (LabVIEW) for some small tweaks?

So where does that leave full-fledged LabVIEW developers? I don't know. As a career advice I wouldn't recommend anyone who wants to be a pure software developer to go for LabVIEW. But I honestly believe using a high-level tool like LabVIEW has its benefits like allowing you to be a domain expert in the field you are operating in while also allowing you to be a develop the stuff without having to focus too much on grit. And I hope having that combination will still make me employable.

Edited by codcoder
added stuff
  • Like 1
Link to comment

Very good thread, keep up the discussion.  I just wanted to chime in on one thing with my opinion.

16 hours ago, pawhan11 said:

Some of my thoughts after working 6 years as 'Labview Developer'

  • LV did not change much over last 6 years, things that I remember were maps, sets, vims and independent runtime engine

I think I understand what you are trying to say with this.  But it seems with every version of LabVIEW, NI focused on at least having a couple important bullet points with every release.  They likely have to split resources between current and NXG flavors, but just for my own categorization I made a list of features that seem important to me with each release.  Looking over the release notes of each version of LabVIEW it is clear that each year lots of work goes into each release.  Its just that some years are more packed with features I care about than other.  

2020 - Interfaces, 2019 - Maps and Sets, 2018 - CLI and Python support, 2017 - VIMs, 2016 - Channel Wires, 2015 - Right click Framework, 2014 - 64bit support in Linux and Mac, 2013 - Linux RT OS for RT targets, 2012 - Concatenating and conditional tunnels, 2011 - Silver Controls and Asynchronous Call by Reference,  2010 -  VI Analyzer and PPLs, 2009 - New Icon editor and Snippet, 8.6 - QuickDrop

Fundamentally dataflow concepts don't change, which is a good thing.  A LabVIEW developer who started on LabVIEW 8.0 could probably do programming in 2020 just fine.  They will discover all kinds of things they never had but it won't be like starting over to them.

  • Like 1
Link to comment
35 minutes ago, hooovahh said:

Fundamentally dataflow concepts don't change, which is a good thing.  A LabVIEW developer who started on LabVIEW 8.0 could probably do programming in 2020 just fine.  They will discover all kinds of things they never had but it won't be like starting over to them.

And this is another thing that makes the jump to NXG less palatable; it is like starting over.

 

Edited by Neil Pate
  • Like 2
Link to comment

Using NXG I don't feel like I am starting over, but do feel like I am programming with one metaphorical hand behind my back.  I have been part of some of the hackathons NI has hosted at NI Week.  There it was important for NI to see developers using NXG for the first time, and seeing what things they could figure out on their own, and get feedback on things.  There was definitely more than one moment where I would call someone over and be like "Look I can't do this thing I always do in current LabVIEW" and they would write things down and without giving the answer they would hint that it was possible.  After a few seconds of looking in menus, and right clicking several times I would discover it is possible but in a different way. 

I don't want to sound like I am defending NXG.  I've used the web technology in a grand total of 1 project and that's it so my experience level is quite low.  And there were several times I would tell someone at NI "Look I can't do this" and they would look confused and ask why I would want to do that.  I'd then give several real world reasons I need to do that or I can't migrate to NXG.  Which probably why my usage with NXG on real projects is low.  Keep the feedback coming.  I want to hear what struggles other people are having, just like I assume NI does.

Link to comment
33 minutes ago, hooovahh said:

Using NXG I don't feel like I am starting over, but do feel like I am programming with one metaphorical hand behind my back.  I have been part of some of the hackathons NI has hosted at NI Week.  There it was important for NI to see developers using NXG for the first time, and seeing what things they could figure out on their own, and get feedback on things.  There was definitely more than one moment where I would call someone over and be like "Look I can't do this thing I always do in current LabVIEW" and they would write things down and without giving the answer they would hint that it was possible.  After a few seconds of looking in menus, and right clicking several times I would discover it is possible but in a different way. 

I don't want to sound like I am defending NXG.  I've used the web technology in a grand total of 1 project and that's it so my experience level is quite low.  And there were several times I would tell someone at NI "Look I can't do this" and they would look confused and ask why I would want to do that.  I'd then give several real world reasons I need to do that or I can't migrate to NXG.  Which probably why my usage with NXG on real projects is low.  Keep the feedback coming.  I want to hear what struggles other people are having, just like I assume NI does.

hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested.

The thing I cannot understand is this... the engineers intimately familiar with LabVIEW today are the engineering managers of tomorrow. NI is pissing off the engineers of today who are the ones signing the purchase orders of tomorrow.

I never intended for this post to descend into a rant session, I am just disappointed that after so much investment by NI this is the product that has been laid on the table. There was no need to revisit change every single decision in current gen, most of the paradigms worked really well. I would literally hold captive anyone even remotely interested in LabVIEW and gush wildly over its amazingness, like a parent gushing over their favourite child. Now when people ask me about NXG I sort of blink and stare into the distance and change the conversation.

 

Edited by Neil Pate
  • Like 2
Link to comment
20 minutes ago, Neil Pate said:

I never intended for this post to descend into a rant session, I am just disappointed that after so much investment by NI this is the product that has been laid on the table. There was no need to revisit change every single decision in current gen, most of the paradigms worked really well.

(Un)fortunately only someone who actually worked with CG is able to tell the difference, which makes NXG easier to sell to new customers than existing ones. Just a few clicks and you get your shiny graphs, overviews or packages. @Aristos Queue mentioned before, that NI lost business opportunities because of the old fashioned UI of CG.

16 hours ago, Aristos Queue said:

Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.

I'm pretty sure we are not the target audience of NXG at this point. Maybe in the future. Until then we can still spend our money on CG. Really, there is no incentive for NI to listen to our complains right now and I don't expect them to. Nevertheless, I'll keep an eye on NXG and on how it evolves in the future. Until then we can share our experience and ideas here and prevent each other from regretting horrible decisions 😉

Link to comment
8 hours ago, LogMAN said:

but why use the same file extension?

Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility.

I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate for end users.

* LV2020 Community Edition became available yesterday. Commercial edition will be later in May... we prioritized the CE release for all the quarantined engineers at home.

  • Like 1
Link to comment
2 hours ago, Neil Pate said:

hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested.

The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.)

I am not on the NXG team, and yet I can point to decision after decision made directly from customer feedback.

  • Like 1
  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.