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.

2 hours ago, Bryan said:

While It's a neat concept by NI, it's a BIG no-no at my company to use USB media sticks that are not explicitly provided by my company for information security reasons. (Anyone remember Stuxnet?)

Stuxnet can be just as easily distributed on CDROMs. The danger of Stuxnet is not in the media. It's in the provenance. For Stuxnet, people found USB drives in the parking lot and used them. It would be the same if you found a CDROM in the parking lot and popped it into your computer. If you really have a blanket ban on USB drives, you may have to download LabVIEW instead of installing it from media -- it doesn't fit on a CDROM anymore, so we don't ship them.

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.

Just now, Aristos Queue said:

None whatsoever while I'm working here.

Following up on that:

http://www.ni.com/white-paper/3574/en/

Search for "multiple inheritance".

On 6/7/2017 at 4:14 AM, 0_o said:

I understand. Any chance LV NXG will support multiple inheritance?

None whatsoever while I'm working here.

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. ;-)

FYI... found a workaround for right now... right-click "Open Front Panel" will display the clone.

Well... that's unexpected. And wrong. I'll file the bug report.

8 hours ago, ShaunR said:

The create event was required to type the queue dependent on wire type so it had to be first and, because it was always created, it had to be destroyed if it was superfluous. If the disable structure propagates the type now rather than sticking as a string regardless of the control type, then I like that very much

To the best of my knowledge it works. If it doesn't for some reason, use a case structure with a constant wired to the ? terminal. That will still get the type and still not create the event unless you need to.

8 hours ago, ShaunR said:

Nice work.

Thanks. It's a brand new feature, so I'm nervous that we've missed a use case somewhere. So far, so good.

13 hours ago, Nikita Prorekhin said:

Other questions (very trivial I guess) that came to my mind:

You'd have to ask a NXG UX designer those questions. All my NXG work is behind the scenes. I don't speak for any of the design decisions of anything you see on screen. In some cases, I can tell you "what" but rarely can I tell you "why". Try posting your questions to the CAB forum or use the feedback function that Mads mentioned above.

On 6/3/2017 at 3:56 AM, ShaunR said:

They work great now and so does my "Named Events!" Woohoo!

srevent.vim

ShaunR: Your code looks like it is working way too hard. Here's a significantly more performant version -- so you don't do the extraneous creation of the event refnum all the time.

Note my comment, though... I preserved your behavior in this code, but I'm curious why you have the feedback node... why would you ever want to return the same event registration refnum multiple times? That's a bug in most G code.

21 hours ago, smithd said:

Since it is an edit time construct, I would assume you can use it in an lvlibp but you can't expose a function from an lvlibp which adapts to type.

Exactly correct.

On 6/3/2017 at 4:02 PM, smithd said:

in the talk they mentioned that while the feature existed they replaced the xnode back-end with something else unspecified (maybe the nodes fpga uses?)

The nodes are just regular subVI nodes. The instances are created using the same tech as Express VIs.

13 hours ago, 0_o said:

Nice! Does it mean that in the background LVOOP started supporting multiple inheritance and one day it will become available to us all?

What? There's nothing about OO in the picture I posted.

On 3/14/2017 at 1:26 PM, ned said:

 Right now you can't do this in LabVIEW.

Welcome to LabVIEW 2017. It'll be even better in 2017 SP1, but this works for now.

On 6/2/2017 at 7:09 PM, ShaunR said:

@AQ.

What is the advice for Toolkit developers? Where does the tools network fit in with this new software?

You'll have to make your own call on when to add support for the new and when to drop support for the old. That's my only guidance. The LabVIEW Tools Network team may have more specific feedback. You can ask them on the toolkit dev forum: http://forums.ni.com/t5/LabVIEW-Tools-Network-Developer/ct-p/7009

53 minutes ago, rolfk said:

Yes the new WebVI technology based on HTML5 is likely the horse NI is betting on for future cross platform UI applications that will also run on Android, iOS and other platforms with a working web browser. Development however is likely going to be Windows only for that for a long time.

This theory is correct. (I'm just the messenger. If you want cross-platform development, talk to your local NI sales engineers and other NI feedback venues.)

On 6/1/2017 at 4:45 AM, Nikita Prorekhin said:

When designing in Visual Studio, you can choose between WYSIWYG, XML or split design modes.

Is it possible to do the same in NXG?

Split design mode, yes, where you can see both panel and diagram. We don't maintain an in-memory XML form, and if you look at the save files, directly editing the XML is a fools' errand (at least for me... I've tried to doctor several such files over the last few years). So if you're asking for an XML format, there isn't one.

On 1/5/2017 at 10:26 AM, ShaunR said:

This sounds like a code smell. I don't think I have ever done that. Is this something to do with classes requiring the same connector for overrides?

Nope. Plain subVIs.

On 1/4/2017 at 4:39 PM, ShaunR said:

I'm not sure I'm understanding this fully. Programmable inputs? How would they be programmed-isn't that what our code is for?

As in, when caller leaves terminal unwired, subVI has behavior X. When caller wires the terminal, subVI has behavior Y. This is distinct from simply using the default value of the terminal.

There is a feature I've wanted in LabVIEW for a long time, pretty much since I started programming in G: The ability to have an unwired input terminal have meaning.

Currently, if you leave an input terminal unwired, you set it to Recommended and you give the control a default value. That doesn't really mean the user left the terminal unwired... they could have wired the default value. That doesn't really help when, for example, all possible integers are valid values for the input. You end up having to add a second Boolean terminal for "should pay attention to integer?" or something like that. Even when you do have a valid sentinel, you may have to add code to check "is the input value the sentinel?" in the middle of your executing code, which is a small but annoying performance hit, and one that can ooch up over time. Think of how many times we check error input terminals and how much of that code could be dead code eliminated if only subVIs generated code specific to their callers. That's a *minor* example. There are a lot more interesting algorithmic changes that are possible for an unwired terminal... some of the built-in primitives of LabVIEW have very different behavior when inputs are left unwired.

Currently, if you leave an output terminal unwired, LabVIEW doesn't care... the value of that output gets computed anyway when the subVI is called because the subVI has only one code path. This has lead me to have to have extra terminals on input for "should compute output X?". You can fix this sometimes by marking the subVI to be "inline" and then when you turn off debugging, the computation code likely gets dead code eliminated. But not always. If the computation involves a refnum, it won't get dead code eliminated. And if there are interim data structures along the way that you populate, those will still get built up if they're part of a downstream terminal that is wired. The compiler probably (IMO) will never be smart enough to analyze and do that level of elimination until the compiler is sentient. So some sort of computation here would be valuable, I think.

I've investigated this before and always hit some limits. I'm thinking I might make another run at figuring out how this could work. No promises, but there's some new ideas out there on code optimization that I might be able to leverage.

The unwired output case is pretty straightforward... I'm not too interested in unwired output cases unless you have one that is radically different from "this output is expensive to compute so I only want to do this part of this larger algorithm when that output is wired".

I am interested in unwired input use cases.

So as part of my brainstorm on this topic (and to gauge whether or not this would have benefit to users other than myself!), I'm curious to hear about any VIs y'all have written where being able to program in unwired terminal behavior would have been useful for you.

There's no deadline on this. I am just sort of musing on this topic lately. I don't know if it will lead to any LV features. I just want to explore this particular topic more.

On 8/16/2016 at 10:29 AM, ShaunR said:

None of the NI products can navigate proxies properly-even transparent ones. I have to connect directly if I want to use any of their download/upload features (updates, the toolkit down loaders, NIER, et al.), 

ShaunR: I don't know enough networking to know what a proxy is, much less the difference between an opaque and a transparent one. That makes it hard for me to file bug reports when I read comments like this. Can you write up more details about what the issue actually is? I might be able to get someone to look into the issue if I could describe it properly.

1 hour ago, hooovahh said:

 I suppose it is too much to ask for a way to detect what type of structure it is through a private method or some super secret tag, or something?

The right way would be To More Specific, but there isn't any VI Server class added for this structure node. I assume Jeff K just forgot to create it.

> For my own interests is there some decent documentation about the undo stack and how that works?

Not really because there isn't much to it -- if you do edits to the VI when there is no transaction in progress, the undo stack gets wiped. If you call Begin Transaction, all edits are logged as part of that transaction until End Transaction is called. I can't think of any other details to document. Do you have specific questions?

> So in my original plugin I did not modify the VI in the build menu part of the plugin and it still crashes.

There may be something else going on. Keep in mind that this structure wasn't added fully to scripting -- there's no specific scripting class for it, so there may be something in LV that is getting confused about its type. This may be a more fundamental issue that has to be fixed in LV 2017 (can't add new scripting classes in SP1 and patches).

> Doing so will always wipe the undo stack.

And since you're apparently sometimes wiping out the thing that LV is right clicking on (the Remove Frame could remove the current frame), I'm guessing that can crash. That's not an operation I ever contemplated anyone even attempting, so I never tested for it.

Don't modify the VI during the builder VI and you should be fine.