LabVIEW 2017 What's new

[bjustice]

Hey guys!

So, I've installed LabVIEW 2017 and I'm starting to play around with it.  Malleable VIs are cool!  (No more giant OpenG toolkits where there are 10 instances of the same VI for multiple datatypes.)

Another cool thing that I've observed is that the example "sort 2D Array" function can support a scalar and an array input for index.  Upon further digging, there appears to be an interesting disable structure that intelligently selects the upstream input that yields non-broken code. 

Does anyone have more information about this structure?  Is this related to the experimental structure that Hooovah talked about in his Xnodes presentation at NI week?  I'm just curious if this is stable... and if I can start using it... and it there is any documentation on it that would tell me how to use it.
 

 

[ShaunR]

They used to be called VI Macros (*.vim). There is a thread on here somewhere (can't find it ATM) that talks about them extensively with examples and such.

[smithd]

As for the structure, you may wish to watch the JeffK+Mercer presentation at NI week you can get here

My understanding: basically it is a disable structure where instead of manually enabling/disabling, the compiler will run through all cases and enable the first case which doesn't cause a compiler error. When used in conjunction with a vim you can do fancy things. For example if you wanted to make 1 node that did "concatenate stuff" you could have two cases, 1 assuming the inputs are strings and 2 assuming they are scalars or arrays. If the type passed in is not a string, that case1 will cause a compiler error and it will go on to case2 with the more flexible build array, which will compile. In the NI week presentation it sounded like it was mostly solid but too early to be comfortable throwing it out to the masses yet. 

[ShaunR]

5 hours ago, smithd said:

 

Thanks for finding that.

The only thing I'm concerned with VIMs was WRT events (no longer changing a load of VIs' indicators just because the data changes). They work great now and so does my "Named Events!" Woohoo!

srevent.vim

[smithd]

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

[hooovahh]

VIMs are amazing and will cause revamping of polymorphic reuse libraries.  I did a talk on this in August at NI Week which covers XNodes and the second half talks about VIMs and this structure which was named "Type Enabled Structure" unofficially in 2016 when it was introduced.

http://forums.ni.com/t5/2016-Advanced-User-Track/TS9451-XNodes-Treasures-of-Reuse-in-LabVIEW-s-Attic/gpm-p/3538650

As others have said it works like a disabled diagram, where it goes through trying to enable each case one at a time and will enable the one that creates no broken wires.  This can mean even more reuse if you can make your code more generic to accept scalars or arrays as it does in this case.

The structure itself is not official in 2017 and has some editor issues.  The impression I get is that it is stable (I mean it has to be NI is using it) but only after the code has been written and compiled.  It still has odd cases where when you are first developing with it, the VIM won't adapt the way you want, but I've found it works just fine with code that is written and tested

[pawhan11]

Ot of couriosity, Can VIM be packed into lvlibp?

When I tried to do that with xnode I cold not, I got to conclsion that xnode was some form of lvlib iteslf...

[ShaunR]

3 hours ago, hooovahh said:

VIMs are amazing and will cause revamping of polymorphic reuse libraries.

..... revamping of [some] polymorphic  reuse libraries.

I've never used polys in that in that way for reasons I have said detailed many times before, so they wont be replacing any of mine. I think the incidence of that use case is overstated and probably only applicable to things like OpenG. A much needed simpler adapt to type XNode is a better comparison than a polymorphic alternative, IMO.

Edited June 5, 2017 by ShaunR

[smithd]

9 hours ago, pawhan11 said:

Ot of couriosity, Can VIM be packed into lvlibp?

When I tried to do that with xnode I cold not, I got to conclsion that xnode was some form of lvlib iteslf...

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.

8 hours ago, ShaunR said:

I think the incidence of that use case is overstated and probably only applicable to things like OpenG. 

FPGA works too, and I've got a few things in an internal library which are basically typed versions of the same code. I suppose there might be a way to nicely oopify it but I'd rather use these.

Edited June 6, 2017 by smithd

[ShaunR]

 

9 hours ago, smithd said:

I've got a few things in an internal library which are basically typed versions of the same code

Indeed. But I think most people couldn't be bothered and used variants or put up with coercion dots, so it is rare.

[Aristos Queue]

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.

[Aristos Queue]

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.

[ShaunR]

13 hours ago, Aristos Queue said:

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.

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

There where a couple of race conditions that were responsible for the complexity. So I'll play with yours in the HAL Demo to make sure, but it looks good.

There maybe a bug in that part of the code, but it probably isn't what you think. The same VI is also used to send events. For example. If you look at the "SOUND.VI" in the HAL Demo you will see this

When retrieving the event we don't want to create huge numbers of event refs in tight loops. We touched on the reason for the register inside the VI rather than requiring the user to explicitly use one in the VIM thread. I also don't like the separate "generate" event but I think only a VIM wrapped in a polymorphic VI could alleviate that and bring it up-to-par with the Queue version (see below). On consideration. Maybe I can see a way without a polymorphic vI, now that type propagation works better. It needs to reliably work when indicators are wired as well as controls and it didn't before.

The corollary of this is the Queue VI which is in all my applications.A single, self initialising VI (from the developers perspective) that can act like "channels" between diagrams and services as well as just on the same digram . It too has benefited from "VIMifying" and no longer requires the developer to use flatten/unflatten to/from string - which was an ostrich approach to the type genericism. The thing that prevented the same treatment for events was the event refnum indicator which was intransigent when changing the data type and just broke any VI it was used in until it was replaced. Not any more Nice work.

Edited June 7, 2017 by ShaunR

[Aristos Queue]

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.

[bjustice]

On 6/2/2017 at 10:29 PM, smithd said:

As for the structure, you may wish to watch the JeffK+Mercer presentation at NI week you can get here

My understanding: basically it is a disable structure where instead of manually enabling/disabling, the compiler will run through all cases and enable the first case which doesn't cause a compiler error. When used in conjunction with a vim you can do fancy things. For example if you wanted to make 1 node that did "concatenate stuff" you could have two cases, 1 assuming the inputs are strings and 2 assuming they are scalars or arrays. If the type passed in is not a string, that case1 will cause a compiler error and it will go on to case2 with the more flexible build array, which will compile. In the NI week presentation it sounded like it was mostly solid but too early to be comfortable throwing it out to the masses yet. 

Smith, thank you for your answer and for linking these pages.  I found them very helpful.

[Bryan]

I just received the "disks" for our SSP today with LabVIEW 2017 and NXT.  I was eager to install and play with it.  But, instead of disks, I received a 32GB USB stick.

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

I'm friends with someone in information security, and I can ask if there are acceptable processes/procedures to use the disk, but I'm pretty sure I already know the answer. 

These are the times when working for the type of company I do is a pain.

[infinitenothing]

FYI, the usb drives use DVD-ROM drivers and are read only.

[hooovahh]

13 minutes ago, infinitenothing said:

FYI, the usb drives use DVD-ROM drivers and are read only.

Yes but I'm guessing the security concern is not stealing IP, but instead plugging in a random USB drive, that might have some malware, or rootkits on it.  Of course this should be no different than putting in a DVD from said company since the USB mounts the same as an optical media, but I guess you wouldn't know that unless you plug it in.  NI has been doing this for various bundles for at least a couple of years now.  I personally like it just so I have one thing I need to copy to the network for network based installs, instead of having to copy 4 or 5 DVDs and then do something to merge them into a single folder so it doesn't prompt for the next disk.

If you want to really discuss corporate policies getting in the way of getting your job done, or the efforts in reinventing the wheel for a large company, then I have lots to say.  I'm not certain that we have the most restrictive policies in the industry, but I know we would be top contenders.

[ShaunR]

32 minutes ago, hooovahh said:

If you want to really discuss corporate policies getting in the way of getting your job done, or the efforts in reinventing the wheel for a large company, then I have lots to say.

That sounds like the start of a great thread topic

[Aristos Queue]

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.

[Mads]

The biggest headache with USB is BadUSB.  

I trust NI will make sure their USBs  are OK though, I do not miss the DVDs (CD-ROMs? That must have been back in the  LabVIEW 7/8 days ;-)).

[smithd]

Considering how long thats been a security concern I'm surprised there isn't something you can buy which adapts a random usb safely to your system. Like a raspberry pi that reformats every time it powers on and automatically exposes any mounted USB as a network share, or something along those lines (or as if its a DVD drive as described above). Or maybe there is such a device and my 10 second google search didn't find it :/

 

Am I correct in saying that there isn't a similar concern with (micro)sd cards? Or do they also have the potential for firmware hijacking?

Edited June 13, 2017 by smithd

[ShaunR]

9 hours ago, smithd said:

Like a raspberry pi that reformats every time it powers on and automatically exposes any mounted USB as a network share,

For standard USB, the malicious code needs to be executed. People get caught out on Windows because they have autorun enabled. Turn that off and a program needs to be executed. Of course, if the malicious code is called "setup.exe" on an NI DVD/USB, you will run it. I've said before. The two things you should always do when getting anew PC is to turn off autorun and set the default operation for VBS scripts to "Open" rather than the default "execute". That defeats auto-infection by most malware even if it is present.

To add to the horrors of USB, try Googling for BashBunny and LanTurtle. When a USB device proffers itself as an ethernet adapter it can take over DNS, download code, spy on all internet traffic, steal windows credentials and is immune to virus scanning.

[Bryan]

18 hours ago, ShaunR said:

That sounds like the start of a great thread topic

I agree with you, but I still have to run it by them before plugging in anything not provided by the company.  You know how large companies can be.  Knee-jerk reactions become long term policy and then convincing them otherwise is like talking to a tree unless you have serious pull within the organization, (which I do not).

I've sent a request asking if there is an accepted process or if I can get a waiver.  If there's no way, then I have to wait for our company-wide VLA to come up to speed... which could be a while.  Currently, they are only providing up to LabVIEW 2015 through our engineering software "store".  As I said in another post, we're normally two to three versions behind (which is why I let my CLD expire).  The only way I'm able to get anything newer has been via the DVDs/CDs and my "pseudo" administrative rights on my computer.

 

18 hours ago, hooovahh said:

If you want to really discuss corporate policies getting in the way of getting your job done, or the efforts in reinventing the wheel for a large company, then I have lots to say.

18 hours ago, ShaunR said:

That sounds like the start of a great thread topic

I would definitely be able to contribute as well!

[hooovahh]

I made a new thread and started with a story that you reminded me of.