Separate category for NXG?

[eberaud]

As topics about LabVIEW NXG are going to start growing more and more numerous, it would be nice to have a proper folder to put them. Could an admin create a dedicated folder or category where it would make the most sense (at their discretion)? 

[hooovahh]

Personally I think this is a good idea, and NI already is doing something similar by tagging NXG posts so they can be identified.  I do think there are some issues with making a new subforum.  One is if we do make an NXG subforum, then what happens when it isn't called NXG anymore?  I've heard that some day NI will just call it "LabVIEW" and the LabVIEW we all know and love might be called something else, like "Classic LabVIEW".  But then again that might not be for many years until NXG has functional parity with LabVIEW.  There are also going to be times when a subject is about NXG and Object Oriented Programming, which subforum should it go into?  Now we'd say NXG, but in a few years would it make more sense to put it in OO?  Anyway I'll talk to some admins and see if we can agree on something.

[Aristos Queue]

Given that G is the same language in both -- the compiler and execution system are [mostly] the same -- I suggest creating a "LabVIEW NXG Development Environment" section. That way it is clear that architecture questions go in the version agnostic section (since the right way to write code shouldn't depend upon the environment), but UX changes go to the version specific. There will be some muddiness as NXG develops (right now, no classes; in the future, gaining components, something the current dev environment isn't planning to develop), but for the most part, I think this would serve best.

For the record, I've got a similar conversation happening inside NI about the Idea Exchange. ;-)

[ShaunR]

54 minutes ago, Aristos Queue said:

Given that G is the same language in both -- the compiler and execution system are [mostly] the same -- I suggest creating a "LabVIEW NXG Development Environment" section. That way it is clear that architecture questions go in the version agnostic section (since the right way to write code shouldn't depend upon the environment), but UX changes go to the version specific.

Except that all the primitives have changed so it is not just a UX "option". It is, to all intents and purposes, a different language and examples, snippets and demos aren't synonymous even if they were in an "architectural" sense.

[Aristos Queue]

8 minutes ago, ShaunR said:

Except that all the primitives have changed so it is not just a UX "option". It is, to all intents and purposes, a different language and examples, snippets and demos aren't synonymous even if they were in an "architectural" sense.

Exactly how far apart the two dialects are and whether they constitute different languages is a judgement call that shouldn't affect the forums. If the person's question does hinge on something that is platform specific, then I would direct them to the specific forum. If it is a more general question, I would not. What I do not think should happen is somehow that all the years of good commentary on software design that LAVA has built up should suddenly be relegated to an "old news" bin just because the UX got a rewrite. So the main headings of

•  Application Design & Architecture
•  Object-Oriented Programming
• Remote Control, Monitoring and the Internet
•  Certification and Training
• Database and File IO
•  Calling External Code
•  Machine Vision and Imaging
•  Real-Time
• Embedded
•  Linux
• Apple Macintosh

I would not fork. The platform-specific ones of

• User Interface
•  VI Scripting
•  Application Builder, Installers and code distribution
•  Development Environment (IDE)
•  Source Code Control
•  TestStand
•  

I would suggest forking.

Similarly, I would not fork "OpenG" -- the API should be the same in both dialects. Apply same rubric for any other subforums.

Edited June 12, 2017 by Aristos Queue

[smithd]

Interesting, why teststand? I would assume nxg would be added as an additional step type (ie lv, nxg, activex, .net, ...). Or did I miss some announcement?

 

Edit:

I see http://forums.ni.com/t5/NI-TestStand/Announcing-the-TestStand-2017-Beta-Program/td-p/3634785
The UI has also been updated to use NXG tools

Edited June 12, 2017 by smithd

[infinitenothing]

NextLabVIEWStand confirmed! 

[ShaunR]

1 hour ago, Aristos Queue said:

What I do not think should happen is somehow that all the years of good commentary on software design that LAVA has built up should suddenly be relegated to an "old news" bin just because the UX got a rewrite

That's my point. The UI didn't just get a rewrite. LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET. All the community contributed code will eventually be obsolete and the forums are example led not white-paper led!

[smithd]

5 hours ago, ShaunR said:

That's my point. The UI didn't just get a rewrite. LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET. All the community contributed code will eventually be obsolete and the forums are example led not white-paper led!

I don't know about that. To pick some examples from the main labview forum:

https://lavag.org/topic/20126-aligning-two-waveforms/
I can't imagine that this would become obsolete. Sure some of the nodes might change (at NI week they showed off how they are distinguishing between two use cases polymorphs currently cover, so maybe we see "feature detection{2d dbl, peak}" rather than just "peak detection.vi"), but i think the valuable part is the discussion here.

https://lavag.org/topic/20151-how-to-draw-circles-and-lines-in-intensity-graph/
Yes this will obviously become obsolete. But, its also in the wrong forum anyway, arguably, as its a user interface question. Lava doesn't have anywhere near enough volume to matter.

https://lavag.org/topic/20169-storingimporting-daqmx-task-configurations/
Will probably become obsolete as well, but ideally in favor of an obvious built-in solution to the problem, rather than a hack

So I mean sure there will be some obsolete stuff during the transition but I highly doubt that will cause many problems

5 hours ago, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

With your past comments on .net I'm assuming you meant this to be insulting, but I honestly think this is a better name. For one thing it rolls off the tongue better than labview nxg, and more importantly it makes it sound like labview is trying to align itself to be more like 'a real programming language' which is nice.

Edited June 13, 2017 by smithd

[ShaunR]

6 hours ago, smithd said:

I don't know about that. To pick some examples from the main labview forum:

https://lavag.org/topic/20126-aligning-two-waveforms/
I can't imagine that this would become obsolete. Sure some of the nodes might change (at NI week they showed off how they are distinguishing between two use cases polymorphs currently cover, so maybe we see "feature detection{2d dbl, peak}" rather than just "peak detection.vi"), but i think the valuable part is the discussion here.

So I mean sure there will be some obsolete stuff during the transition but I highly doubt that will cause many problems

Snippets are code. There are many examples in that thread and the litmus is to take them out and see how much sense the thread makes, You can't rely on them purely as images anymore because all the icons have changed! (e.g " Here I've used it just to shift each waveform"). I've always hated snippets but if LabVIEW.NET ( ) can accept all the old ones like LabVIEW does now and .NET ones can be dropped into LabVIEW,proper, as is. Then it may mean there is no reason to have different topics at all.

Edited June 13, 2017 by ShaunR

[Aristos Queue]

On 6/12/2017 at 4:54 PM, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

This is false. Where did you get this impression?

On 6/13/2017 at 3:00 AM, ShaunR said:

 I've always hated snippets but if LabVIEW.NET ( ) can accept all the old ones like LabVIEW does now and .NET ones can be dropped into LabVIEW,proper, as is. Then it may mean there is no reason to have different topics at all.

I don't think I've heard anyone propose this. The forward direction from current platform to next platform is certainly a possibility. I'll propose it to the team.

[Aristos Queue]

On 6/12/2017 at 4:54 PM, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

Wait... I think I understand what you mean... I took "LabVIEW.NET" to mean a .NET execution engine and requiring .NET programming.

You just mean that eventually everyone will be using LabVIEW NXG, right? Ok. That's true. It's years away, but, yes, that is the migration path. But the current platform VIs can be migrated by users. And your suggestion about allowing snippets to drop directly is a good one.