What is stopping you from switching to LabVIEW NXG? - VI server

[Jay14159265]

If you think its bad in NXG, don't even look at the NXG web-module. There is about 5% of the control of UI objects you get when running full LabVIEW, and it is by nature a web-page and thus a UI you might say. You don't get mouse events?!?!?!

[RTSLVU]

Last time I checked NONE of my instruments were supported in NXG.

I have too many third party instruments in the lab and not enough time to write instrument drivers from scratch using SCPI commands

[MrJackHamilton]

Agree 100%

Frankly, I don't know nor has NI ever stated "What problem NXG is trying to solve"

LabVIEW has a long development and improvement pedigree that should only continue.

As a long time LV programmer, there is a many features and need robustness that LabVIEW code can benefit from.

My concern is NI software development has create a branch in the road....And one of those roads has a significant portion of LabVIEW programmer are on...the other does not.

NXG looks to me like the Fisher-Price interface to LabVIEW...Very dumbed down and simplified.

Regards

Jack

[TroyK]

---

@MrJackHamilton wrote: ...NXG looks to me like the Fisher-Price interface to LabVIEW...Very dumbed down and simplified.

---

TBH I haven't used NXG enough to evaluate the functionality of the updated UI/IDE.  But in my opinion the LabVIEW classic IDE really needs an update.  It's looking outdated.  It needs to support vector graphics on the FP for example.  NXG seems to address these issues, bringing the IDE nicely into the 2020s.

The reason I haven't used it much is because I need to be able to port my existing projects into it without losing dependencies or too much rework.  Until that is possible I don't have time to play around with something I will not be able to use yet anyway.

The progress in NXG 4.0 is actually looking promising.  Now I just have to get NI to send me a properly updated license file so I can activate 4.0 and give it a go.

[MrJackHamilton]

Troy,

I agree, LV needs quite a few updates to enhance the fluidity of use and the UI could use some much needed attention. The front panel has not been updated in decades.

This was hinted in my comment about a branch in the development road for NI. Resources will not be spend on LabVIEW core, which needs a robust path of updates and enhancements.

Now if NXG was implemented as an alternative development UI for LabVIEW core. I can see and would be excited about that development path.

Again, I simply can't conceive what problem NI perceives that NXG is trying to solve. I think Express and some of the other add-ons with LabVIEW were good ideas for simple, acquire, plot and save applications.

Like you, we have decades invested in code on the broad array of NI hardware. I have numerous VI toolkits we've created, that drop in...and replace several hours of coding and debug. Which on large projects, would add weeks to development and unnecessary risk.

I'm not looking to start from scratch unless I see a compelling rationale to do so.I don't think NI ever posed this question when choosing to start creating NXG. Hence, why here on the forums users keep asking this same question, over and over.

Regards

Jack

"The code does what you program it to do...not what you *want* it to do..."

- Jack Hamilton

[wiebe@CARYA]

---

@MrJackHamilton wrote:

Again, I simply can't conceive what problem NI perceives that NXG is trying to solve. I think Express and some of the other add-ons with LabVIEW were good ideas for simple, acquire, plot and save applications.

---

One problem is (probably) (the lack of) Unicode. LV CG was started 30 year ago, and the code page hell (that was great back then) is now embedded in CG core.

Another problem is (probably) the rigidity of the front panel. Being at the core of CG, there's just no easy way to fix it in CG.

A big problem NXG will address is the extendibility of the IDE. CG is very rigid in that. The provider framework, and several plugin mechanisms, are not as flexible as NXG already is. 3Rd party development tools will be much easier to make and better.

---

@MrJackHamilton wrote:

Like you, we have decades invested in code on the broad array of NI hardware. I have numerous VI toolkits we've created, that drop in...and replace several hours of coding and debug. Which on large projects, would add weeks to development and unnecessary risk.

---

The alternative is that CG development just stops, because the code base is just not manageable anymore. LabVIEW will get passed left and right by competing languages\platforms, until development can't be justified.

That will invalidate our code base completely.

---

@MrJackHamilton wrote:

I'm not looking to start from scratch unless I see a compelling rationale to do so.I don't think NI ever posed this question when choosing to start creating NXG. Hence, why here on the forums users keep asking this same question, over and over.

---

You probably don't need to start from scratch. Code can be imported, time will tell how much...

Also, rewriting something based on knowhow will make development easier, so you won't start over.

I get the frustration. It felt like a solution to a problem nobody has to me too. But now I do feel something needed to be done.

The transition period is pretty generous, compared to other multinationals who just pull the plug.

[cbutcher]

Today I checked the roadmap and see cRIOs in the "Next Release" column at last! (or at least, "Gain initial support to deploy to CompactRIO with NI-DAQmx and PXI systems running NI Linux Real-Time OS", which might cover me depending on my level of optimism...)

So maybe the next release is the one I'll start looking at more seriously 🙂

But it'll probably still be a few more before I'm wanting to move all the code I have (and that's not a large amount compared to huge, many-developer companies) to NXG from CG.

Edit: but now I see in the far right "Future Releases" column the following:

Real-Time Programming
■ Perform object-oriented programming using the LabVIEW Real-Time Module

so maybe still a little while.

Still, I think it will be great someday.

[wiebe@CARYA]

Recently found out (can't find the thread now) that although you can dynamically create controls (which is great!), you can't dynamically register for (value change) events. That makes it pretty pointless for now. Although it's still more that what CG can do 😁.

I guess dynamic event registration for controls will be added soon, but it is a show stopper.

[RTSLVU]

---

The reason I haven't used it much is because I need to be able to port my existing projects into it without losing dependencies or too much rework.  Until that is possible I don't have time to play around with something I will not be able to use yet anyway.

---

There's that too... I just don't have time for pre-beta software

@MrJackHamilton wrote:

Again, I simply can't conceive what problem NI perceives that NXG is trying to solve. I think Express and some of the other add-ons with LabVIEW were good ideas for simple, acquire, plot and save applications.

Like you, we have decades invested in code on the broad array of NI hardware. I have numerous VI toolkits we've created, that drop in...and replace several hours of coding and debug. Which on large projects, would add weeks to development and unnecessary risk.

I'm not looking to start from scratch unless I see a compelling rationale to do so.I don't think NI ever posed this question when choosing to start creating NXG. Hence, why here on the forums users keep asking this same question, over and over.

Regards

Jack

Very well said Jack.

Frankly I have found no use for Express vi's and I think they are detrimental to new users. Express vi's  were developed for those two hour LabVIEW seminars to sell LabVIEW managers and other "decision makers" by showing them how fast you can just throw something together using them.

[MrJackHamilton]

CARYA,

Thanks for your comment and clarifications.

The question in my mind is...

The LabVIEW coding environment is an 'abstraction' of text code development. As an abstraction - could it not be possible to recode to abstraction to another development core?.

I would suppose that NXG is that approach. 

For example, the LV Front panel is outdated to be sure. But cannot the diagram abstraction of a front panel object be recoded to the diagram from a new 'FP'?.

What's jarring about slash-and-burn old LabVIEW over NXG is having been using LabVIEW since the year started with a '1'. Me and other developers have stumbled, falled, bleed out and died on the many feature rollouts of LabVIEW.

Notifiers, Queues, BlueTooth. OLE, DDE, .NET., The XY Data to Graph VI, Traditional DAQ to DAQmx, FOR Loop not executing at all on '0' index.

Honorable Mention to: Scared Variables, Sad Engine