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

[TroyK]

---

@EricR wrote: ...open up a new thread on the things you like about LabVIEW NXG that you want to see in LabVIEW in future releases.

---

Good idea! - here it is...Good things from NXG that I would like to see brought over to LabVIEW classic

[wiebe@CARYA]

---

@EricR wrote:

I also recommend that you close this thread and open up a new thread on the things you like about LabVIEW NXG that you want to see in LabVIEW in future releases.  

---

A moderator has to close it... We're almost done anyway (in a few weeks, months, years 😁), might as well keep it open.

It's all very easy to comment on these things in hindsight from the outside, seeing only our cards...

Keep in might that we are (also) deeply invested. We have to talk about these things because we care. 

[wiebe@CARYA]

Terry Stratoudakis

If anything, this becomes a case study in the refactor vs. re-write world. Others (NI DAQmx) worked out (as a re-write). 

I didn't and don't use DAQmx much, but IIRC it was far from painless.

[crossrulz]

---

wiebe@CARYA wrote:

Terry Stratoudakis

If anything, this becomes a case study in the refactor vs. re-write world. Others (NI DAQmx) worked out (as a re-write). 

I didn't and don't use DAQmx much, but IIRC it was far from painless.

---

It was a completely different API.  So most of the pain was from customers having to update all of their code to use DAQmx instead of "Traditional" NI-DAQ.  Otherwise, I don't remember much pain from the change.  Granted, I had just started using LabVIEW right before DAQmx 1.0 was released.

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

Terry Stratoudakis

If anything, this becomes a case study in the refactor vs. re-write world. Others (NI DAQmx) worked out (as a re-write). 

I didn't and don't use DAQmx much, but IIRC it was far from painless.

---

It was a completely different API.  So most of the pain was from customers having to update all of their code to use DAQmx instead of "Traditional" NI-DAQ.  Otherwise, I don't remember much pain from the change.  Granted, I had just started using LabVIEW right before DAQmx 1.0 was released.

---

I mend rewriting took a long, long time. I think much longer that estimated. The result 'worked out' (I'm not a fan, but there was no OO), I'm not sure if it's advertisement for rewrites. But it was a long time ago. 

[rolfk]

I ported several applications from NI-DAQ to DAQmx. While the APIs were different the porting effort wasn't that extreme once you understood the new API. Overall the DAQmx API is much-much more consistent and logical than the NI-DAQ API was. Yes it was some work to port an application but less work than writing a new app using NI-DAQ!

[Kevin_Price]

I'm on record with some grumbling on the forums when DAQmx came along, but I think that was mainly a resistance to feeling forced into a "new thing" when I was already knowledgeable and productive with the "old thing."   I looked up a few of my old posts and there weren't many *specific* complaints thinking things were *worse*, other than a couple soon-to-be-fixed bugs, and an early lack of support for certain corner case features.

I was *immediately* onboard with its multithreading support -- that was the "killer feature" that prompted me to order a new-ish M-series board that required the DAQmx plunge back around 2004.  The cascading DAQmx properties have very much proven their worth for back-compatible addition of features (old code that doesn't use new features won't break), revealing my early gripes as short-sighted.

Anyway, yes there was some pain at the time, but it was pretty manageable.  Historical boards (E-series, TIO series, many S-series) had dual support under both DAQmx and traditional NI-DAQ for a number of years, plenty of time to plan and implement a transition.  

Overall I'd give DAQmx a solid thumbs up when it comes to judging total rewrites. 

-Kevin P

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

Terry Stratoudakis

If anything, this becomes a case study in the refactor vs. re-write world. Others (NI DAQmx) worked out (as a re-write). 

I didn't and don't use DAQmx much, but IIRC it was far from painless.

---

It was a completely different API.  So most of the pain was from customers having to update all of their code to use DAQmx instead of "Traditional" NI-DAQ.  Otherwise, I don't remember much pain from the change.  Granted, I had just started using LabVIEW right before DAQmx 1.0 was released.

---

I mend rewriting took a long, long time. I think much longer that estimated. The result 'worked out' (I'm not a fan, but there was no OO), I'm not sure if it's advertisement for rewrites. But it was a long time ago. 

---

I was referring to the time it took NI to rewrite DAQ to DAQmx...

[donkdonk]

No further discussion required. NI decided to 'pull the plug' on LabVIEW NXG. Must have been a tough decision 😞.

I hope the NXG developers will still be motivated by the large community using 'old-style' LabVIEW.

[1100fps]

Well Crap. I have tried to make projects in NXG, and always hit a wall with missing functionality.  In searching for a solution for another barrier, I find that NXG does not have a future. Sigh.. Lots of hours down the drain over the last 2 years.  NXG had some nice features.  OK.. It's time to rewrite the project in 2020.  I suppose that on the good side, I hit the wall early, so only a few more hours down the drain.