Re : Re: Mini-Nugget Save time wiring shift registers

[parthabe]

Maybe OT, but is there a way to enable the Scripting features in LV 8.5?

I ve tried all possible combinations in the LabVIEW.ini file, but in vain.

[tst]

To have an entry in the Tools menu you need to place the VI in the LabVIEW\Project folder.

---

parthabe wrote:

is there a way to enable the Scripting features in LV 8.5?

---

Not without a license (which you probably can't get). You should be able find some workaround tools in the LAVA forums.

[Wayne.C]

Ben, 

As usual you have stirred up a hornets nest of good ideas.  

JB,

I was sitting at my pc yesterday staring at a vi that used the State Diagram Editor pondering the best way to indicate on the block diagram that the SD editor had been used.  DOHHHHH.

Thanks for sharing such a simple solution. 

[Ben]

Centerbolt posted

Ben, 

As usual you have stirred up a hornets nest of good ideas.  

Not ME, rather US.

That is one of the reasons I try to sneak in a Nugget every now and then. Nuggets are like a Virtual User Group meeting (that never ends) where all attendees contribute a bit hear and there. Without the strength of the LabVIEW Community the Nuggets would be like a VUG meeting were nobody showed up.

Ben

[Wiebe@CARYA]

"parthabe" <x@no.email> wrote in message
news:1208511604971-691930@exchange.ni.com...
> BTW, can you tell me where to put that VI so that it shows up inb the
Tools menu like the Code Capture Tool?
> I ve forgotten that also. Too worse of me.

Put in in your project directory.

Regards,

Wiebe.

[JB]

---

centerbolt a écrit:

Thanks for sharing such a simple solution. 

---

May be we should start a "To simple to be mentioned" discussion in the breakpoint board...

[tbob]

I'm joining this discussion a little late but here is another idea.  In response to JB's post about putting a large cluster in a separate vi:

Use of the VI :



Here is a method to put the large cluster in the same vi that you are using, without having the large cluster take up a lot of room to the left of the loop structure.  Create a case called Local Defs.  Put the cluster inside the Local Defs case.  Wire the output to a shift register.  Use this shift register in all other cases to get values and to write values (unbundle and bundle).  The Local Defs case does not have to be called.  The data type will be on the shift register at the start of the vi.  Leave the left side shift register unconnected (not initialized).  If you need it to be intialized, just call the Local Defs state to intialize to values you have set in the cluster.

I've seen one person even include the error cluster inside the Local Defs cluster.  Unbundle it to retrieve the error wire, bundle it to pass the error on.  This saves yet another shift register.

[Ben]

Talk about "thinking INSIDE the box"! Nice idea tbob.

Here is a question that I suspect nobody will have any idea what I'm talking about (so what else is new).

Has anyone else noticed how the order of cases (i.e. right-click re-arrange cases) can control the data type of a tunnel?

If I can re-create that behaviour I'll post but in the meanwhile,

has anyone else seen something like that?

Ben

[tst]

---

Ben wrote:

Has anyone else noticed how the order of cases (i.e. right-click re-arrange cases) can control the data type of a tunnel?

---

I haven't looked into the rules which govern what the data type of an output tunnel will be, but I have also run into cases where if the specific data type is determined by some nested structures LabVIEW will select the generic data type (e.g. DBL instead of I32) unless you coerce to the type you want.

I can think of one place, so I can try playing with the code there to simplify it and make the behavior come out. If you want to play with it yourself, it's the code inside the AE of the tool I posted here. If you'll look, you will see that many cases have a conversion to I32, because I simply added one whenever it changed to DBL. You should note that the code there is pretty ugly, but it was written using experimentation during little free time, so it has sort of grown itself. That code also demonstrates the use of multiple SRs, because I was concerned for performance.

[DavidBoyd]

Late to the party as usual!  Let's see, in no particular order:

1) The Tunnel Wiring Wizard is elusive because it sets a private property on itself called 'Set Close If Lonely', which means, "Hey - the user has no other VIs open - so I'm no longer needed!".

2) The TWW does not appear in the VI Hierarchy because I used another private property to declare it a 'System VI'.

2) Ben, the TWW does not add any unsupported scripting features to the user's code, but only uses editor features, so I would assert that it's perfectly safe to use to develop production code.

4) It was reworked by Stan Rumega to keep it compatible with 8.2 and again 8.5.  LV Object class IDs changed, multiple application instances got added to LV, etc.  If you drop it as a subVI and open its BD, you'll see that it's very large and ugly.  All the ugliness is mine - mostly due to the fact that it polls (through VI server scripting) to see if it has work to do.  If only there were scriptable 'events' to register for.

5) It's likely to become irrelevant, as tst suggested.  That's all I'll say about that.

Dave