VI macros?

[Aristos Queue]

1 hour ago, Darren said:

I think ShaunR wrote a .vim that provided the ability to name user events, but it didn't work quite right?

Oh. I see the older post. I'd forgotten about that idea.

ShaunR: It's a good thought you had, but, no, this doesn't change anything with respect to constant propagation or anything like that.

[JKSH]

(EDIT: D'oh, half an hour too slow)

2 hours ago, Aristos Queue said:

I don't understand. Why would you expect VIMs to have changed anything with respect to events? This is an edit-time feature, not a run-time feature. Can you explain the link that you're seeing? 

Naming user events is an edit-time operation.

If I write a subVI that generates and outputs a user event refnum, call the subVI twice, and then register both events at the same event structure, I will get two cases with the same event name (which equals the label of the subVI's output terminal). The workaround consumes a large amount of real estate:

(Image taken from http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Name-User-Events-at-Runtime/idi-p/2592841 -- ignore the "runtime" part of the title)

I haven't dug into VIMs myself yet, but if they provide a nice way to label the output refnum, that would be very very nice.

See also this highly-kudo'ed idea, which seems to be catalysed by the desire to name user events: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213153

Edited June 14, 2016 by JKSH

[Aristos Queue]

JKSH: I wasn't commenting on the pros/cons of naming/renaming user events. I just wasn't seeing the connection to this feature. :-)

[bbean]

15 minutes ago, JKSH said:

(EDIT: D'oh, half an hour too slow)

Naming user events is an edit-time operation.

If I write a subVI that generates and outputs a user event refnum, call the subVI twice, and then register both events at the same event structure, I will get two cases with the same event name (which equals the label of the subVI's output terminal). The workaround consumes a large amount of real estate:

See also this highly-kudo'ed idea, which seems to be catalysed by the desire to name user events: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213153

Some self promotion here, but have you tried or seen this:

 

[ShaunR]

 

7 hours ago, Aristos Queue said:

Oh. I see the older post. I'd forgotten about that idea.

ShaunR: It's a good thought you had, but, no, this doesn't change anything with respect to constant propagation or anything like that.

Sour. The one use-case where VIMs finally solved a [decade old] problem and was getting me so excited that I wrote a whole demo on it - VIM HAL Demo). Is only going to solve half the problem,

I'm getting the JSON blues feeling

 

 

[Rolf Kalbermatter]

On 10-6-2016 at 0:06 PM, lordexod said:

I know you're not with NI.

I was hoping for the answer of someone with NI, who appeared recently in this topic.

NI's stance on such things (and basically any company in the US and most other places) is: We do not comment on internal developments, plans for development or lack thereof or whatever, unless we are at a stage with it that it is ready for prime time.

It may sound dissatisfactory for us mere users, but reality is that there are simply to many legal and other implications in our modern system, that speaking before the fact can have far reaching consequences. Basically every employee knows that commenting on unreleased products or technologies without approval from higher management might be the signature under a resigning letter that has no possibility for reappeal.

So you can hope for a reaction from someone from NI about this, but unless they have it ready to be announced at coming NI week you can keep waiting until the hell freezes over. Even then it is not likely that they will react here.

[lordexod]

3 hours ago, rolfk said:

NI's stance on such things (and basically any company in the US and most other places) is: We do not comment on internal developments, plans for development or lack thereof or whatever, unless we are at a stage with it that it is ready for prime time.

It may sound dissatisfactory for us mere users, but reality is that there are simply to many legal and other implications in our modern system, that speaking before the fact can have far reaching consequences. Basically every employee knows that commenting on unreleased products or technologies without approval from higher management might be the signature under a resigning letter that has no possibility for reappeal.

So you can hope for a reaction from someone from NI about this, but unless they have it ready to be announced at coming NI week you can keep waiting until the hell freezes over. Even then it is not likely that they will react here.

The management shall be granted in this topic.

Provides information about product content, which is not yet officially available.

So it does not hurt to ask for things that already are in the products.

[Darren]

On 6/13/2016 at 2:11 PM, Darren said:

Jeff added 6 .vims to [LabVIEW 2016]\user.lib\macros, including the Norm.vim he mentioned.

Oops, spoke too soon. I saw these in an internal build image and assumed they were in the installer. They are not, so they will not be in the LabVIEW 2016 install. Sorry to get y'all's hopes up.

[hooovahh]

Oh that's too bad, well thanks for the update Darren, the day 2016 was available for download I would be posting here asking where this is.  Jeff since you see there is plenty of interests on this topic, would you consider posting this alpha level VIM in August when 2016 is officially released?  I think you would get some valuable feedback from the community, and of course it would be made known just like VIMs are today, a use at your own risk technology, and not to come crying to NI if things break just like several other things we already deal with, like private methods.  I'm actually presenting on XNodes at NI Week, and I was keeping a slide blank to discuss VIMs, and I was hoping this new feature could be something I could mention.  If not I understand and can't wait for some of this R&D stuff to make it to the community.

[jeffk]

The macros are not part of the Windows LabVIEW 2016 install but they ARE part of the Mac and Linux installs!  I will definitely post them here as soon as 2016 is available.

[hooovahh]

Thanks Jeff, I owe you a beer.   Redeemable at the LAVA BBQ if you're interested.

[ensegre]

Quote

The macros are not part of the Windows LabVIEW 2016 install but they ARE part of the Mac and Linux installs!

And are they supposed to work as such there? Perhaps only with an appropriate key? (I have tried ExternalNodesEnabled=True and
XnodeWizardMode=True at no avail).

I remarked since many versions the presence in palette of

/usr/local/natinst/LabVIEW-2011/user.lib/macros/ExponentialAverage.vim
/usr/local/natinst/LabVIEW-2011/user.lib/macros/IncrementArrayElement.vim
/usr/local/natinst/LabVIEW-2011/user.lib/macros/IsArrayEmpty.vim
/usr/local/natinst/LabVIEW-2011/user.lib/macros/IsValueChanged.vim

but never understood what those type limited, odd leftover-like .vi(m!) were dropped there for. In fact, I even happened to grab and modify IsValueChanged.vi, changing its input to variant "for more generality", for perusal in my code. And, as for https://decibel.ni.com/content/docs/DOC-43686

Or am I missing something?

Edited June 30, 2016 by ensegre

[jeffk]

ExternalNodesEnabled=True is needed for LabVIEW 2015 and before, but not for LabVIEW 2016.

It looks like StallDataFlow was dropped as a regular subVI rather than as a macro.  Perhaps you opened the panel of the .vim and dragged the icon to your diagram?

To use a macro you should popup and drop it from the palette or from Select a VI...  

When you get the dialog you have to enable All Documents in order to be able to select it. 

[ensegre]

Right, on second attempt it is working . (I was always choosing from palette, wasn't I?) So did I mistype ExternalNodesEnabled on the first?

QD also seems ok. Thx!

I guess I can't ask about wire adaptation rules, nor "You linked something to me! Here its help stuff instead of my usual dummy text and link...enjoy!", but I'd have to figure them out, otherwise where's the fun.

Edited July 2, 2016 by ensegre

[jeffk]

Rules?  No rules!  The inputs adopt whatever types are wired up to them-- the vim diagram is simply inlined in the caller so type prop works as usual-- whatever gets propagated to the outputs appears on the output wires.  If there's a type prop error in the vim diagram (visible using the xnodewizard) the caller vi is broken.

[lordexod]

On 14.06.2016 at 2:56 AM, bbean said:

Some self promotion here, but have you tried or seen this:

 

New non-xnode update for "Re-Label Wire Xnode" popup plugin Relabelizer.llb , copy to ..\LabVIEW <version>\resource\plugins\PopupMenus\edit time panel and diagram.

[hooovahh]

Okay now that LabVIEW 2016 is out, and the Mac version of 2016 is also out, I went and downloaded these VIMs that were in the user.lib.  I hope I'm not doing anything wrong in posting them here, because these are files that are just available in the evaluation install anyway.  

When asking around the unofficial name for this new structure that automatically enables which ever case has no broken wires is the "Type Enabled Structure".  It looks and behaves very similar to the disable diagram structure but specific cases cannot be enabled by the developer, and the border is a bit thicker.  As always with unofficial features, don't be surprised if it changes functionality, or support, or gets removed with new versions of LabVIEW.

My presentation on XNodes, and VIMs is available here, under the 2016 Advanced User Track.

2016 User.lib Macros.zip

[jacobson]

Since there doesn't seem to be a good way to get this structure from the palette I created a right-click plugin that will replace a Diagram Disable Structure with the new Type Enable Structure. If you right-click a DDS, you will now see the option to "Replace with Type Enable Structure" underneath the "Replace with Conditional Disable Structure".

As a warning, LabVIEW doesn't seem to like what I did and will crash sometimes when undoing or when replacing a TES with a TES. If you can easily see what I did wrong please let me know. Also, if you can find a way to figure out when you have right-clicked a TES and not a DDS it would help solve the second problem.

Replace with TES.llb

[hooovahh]

So I'm apparently terrible at handling the undo stack but I can detect when you right click a TES or a DDS.  All you need to do is attempt to change the enabled case away from the current one.  A TES can't have an arbitrary case enabled, it will always enable the first one with no broken wires.  So with scripting you try to enable case 1 and if it doesn't get enabled then it is a TES if it does get enabled it is a DDS.

I tried fixing the undo but I just couldn't figure it out.  Currently right clicking on any structure will wipe away the undo stack.  I tried doing a begin and fail but an undo begin has already started as part of the right click API so I'm not sure what to do in that case.

Replace with TES.llb

[jacobson]

Didn't know about the case changing. I did a quick search through properties after finding that the style still reported that the TES was a DDS (even though there is a style for TES) but didn't find anything I thought would be too useful.

I also ran into the same problems when trying to start/end a transaction. Crash dumps do report having "Replace with Type Enable Structure" in the undo stack so something is starting/ending it. I'm not sure if messing with this would even help but the crash dumps report a whole bunch of fatal insanities and problems with undo.cpp which is why I was looking into that. It was the first time I've ever seen "Exception: Unknown (0x00000000)" though which I thought was interesting.

[Aristos Queue]

5 hours ago, hooovahh said:

So I'm apparently terrible at handling the undo stack

You can't modify the VI at all in the builder VI. Doing so will always wipe the undo stack. You are setting "Active Frame" during the builder VI. You are also deleting frames by calling Remove Frame. None of that should happen in your builder VI. The only modifications to the block diagram should happen if and only if the user actually clicks on your menu option. Looking at your code, I can't see any reason for the code in the For Loop in "Replace with TES.vi" to even exist.

[Aristos Queue]

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

[hooovahh]

So I'm not changing the calling VI for the fun of it, and I believe I'm doing it in a safe-ish way.  I know it isn't conventional but it has a purpose.  And the intent is to leave the VI the way it was found when the user right clicked.

So the the purpose of the code in the for loop is to detect if the disabled structure that was right clicked was a normal Disabled Diagram Structure, or a Type Enabled Structure.  I could only think of two ways to determine what type of structure was clicked on.  Either export an image of the structure and do some image analysis on it since the borders differ, or the more obvious solution was to try to set a case to be enabled and then see if it actually gets enabled.  If it doesn't then that means the structure is a Type Enabled Structure, and if this is the case then I don't want the menu to show up to replace it with a Type Enabled (because it already is one).

As for the creation and removal of frames.  I thought of a case where a structure exists with only one frame that is already enabled, how could I test to see if this is a DDS or a TES?  So if there is only one frame, then I add a second frame, try to enable it, and then delete it when I'm done, so the user couldn't have right clicked that frame, because it didn't exist until after entering the builder VI.  So if I enabled a case for a test I will enable the original one back, and if I added a frame I will remove it with the goal being that the VI is untouched, with the only purpose being to detect what type of structure it was the user clicked on.

But to be fair I can think of another solution.  I could copy the structure to a new temporary VI, then do this test on the newely pasted structure, but that sounds slower, especially if there are N structures to evaluate.  Maybe the image manipulation method would be better.  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?

Edit:  It seems my other method might not work either, is getting the image of a object resetting the undo stack as well?

[jacobson]

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

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

Edit: forgot to mention it never seemed to crash when actually changing the structure, mostly just undoing as far as I remember. I couldn't get consistent steps to cause this though so I'm not really sure.

[Aristos Queue]

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