LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Highlighted

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?!?!?!

0 Kudos
Message 11 of 52
(612 Views)
Highlighted

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

-------------------------------------------------------------------
Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
0 Kudos
Message 12 of 52
(609 Views)
Highlighted

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

Message 13 of 52
(556 Views)
Highlighted

@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.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Message 14 of 52
(533 Views)
Highlighted

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

Message 15 of 52
(507 Views)
Highlighted

@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.

Message 16 of 52
(493 Views)
Highlighted

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.


GCentral
Message 17 of 52
(350 Views)
Highlighted

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.

0 Kudos
Message 18 of 52
(344 Views)
Highlighted

 

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.

-------------------------------------------------------------------
Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
0 Kudos
Message 19 of 52
(309 Views)
Highlighted

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

Message 20 of 52
(270 Views)