LabVIEW Scripting Main Board

[F._Schubert]

You can try using google cache.

I'm myself struggling with some stuff I know there is a thread about on LavaG.

If anyone knows: How to assign an event in LV 7.x?

[sgregor249]

Thank you guys, google cache did the trick for me. I now know how to expose some more properties and methods.

[BradyDuggan]

We are currently assessing the demand for Scripting in older verions of LabVIEW than 8.6 (LV 8.5, 8.2). Depending on how demand stacks up against the effort it takes to get the installers made, tested and posted... we'll see if we can get it out to you. If you do want it released for a prior version, I recommend being vocal about it so that we know you really want it. Any justification why you need it in the eariler version might help too. Glad to see you all are excited about Scripting though and I hope we're able to satisfy your needs so you can go on making those killer apps.

As for Mac and Linux, the ini token mentioned in the install process for 8.6 will also enable most Scripting features in some earlier versions of LabVIEW. However, at the least, you will not have the extra menu file that was necessary to show the "New VI", "Open VI Object" and "New VI Object" functions in the palettes. Not sure what else doesn't work, so use at your own risk.

[TrevorChristman]

Hfettig,

  Today there is no way to create a new user-defined object unless it has been saved to disk.  I'm evaluating whether LabVIEW will or will not provide a way to create unsaved objects in a future release.

  -Trevor Christman

[TrevorChristman]

Joe,

  In LabVIEW 8.6, the 'Block Diagram:Bounds', 'Block Diagram:Open' and 'Block Diagram:Origin' properties are incorrectly marked to be available only to internal NI employees.  For now, if you wish to use these properties you will have to copy and paste them from any VI where they have already been placed.

  I have provided a blank VI with these properties on the Block Diagram here.

  There are a number of reasons we might mark a property or method to prohibit external use.  These reasons include:

• properties/methods which have not received sufficient testing.
• properties/methods which require careful use to avoid putting LabVIEW into an unsafe state
• properties/methods which we do not expect to maintain consistent behavior between versions of LabVIEW.
  

  These properties were erroneously marked private, and will be marked public in a future release of LabVIEW.  Other erroneously marked properties and methods will be posted in the documents section of this group as they are discovered.

  If anyone knows of other private methods they think should be marked public, I would appreciate hearing your input.  You can reach me at Trevor.Christman@ni.com.

[sth]

Well everyone knows how I hate being vocal.... 🙂

As for our operation we are frozen at LV 8.5.1 for awhile.  At least until all my Power PC processors retire.  Since I still have about 53% of those CPUs around (old Macs never die, but keep taking data!). Thus enabling scripting for that version is necessary if I am to use it.

Yes, I used the ini token to enable it on 8.5.1 on my desktop as a test.  It doesn't seem like it is really mainstream there and missing some of the features that are in 8.6 or 9.  Maybe by the time LV 10 (X?) comes out I will finally be migrated to intel and can update my systems.  In the meantime any support for scripting on 8.5.1 would be cool.

[vugie]

Well, I'm still with 8.2 because I still have not reason good enough to switch it for something higher... And I know the cost of changing something which is good to something which is modern

Currently I'm intensivly developing VIpreVIEW (unfortunately LAVA is not working, but here and here you may find google cache extraction with brief description of what is it and recent results) so possibility of accessing properties without using current dirty methods would help me a lot.

[swatts]

Hi Guy's,

Enjoying the scripting tool very much. I'm a bit stuck though. I have a feedback node outside a multi-frame case statement and am trying to auto-wire the inputs and outputs through the aforementioned case statement.

Any clues would be appreciated

[NJKirchner]

What kind of operation are you trying to script?

A full build of this vi from a blank block diagram?

The reason that I ask, is to determine if this is an interactive kind of operation you want to do where you select both terminals and call the scripting code to connect these two,

or rather a situation where you've used scripting to drop all items and you would need to programatically find the terminals on the case structure.

Each example requires different tactics.

But if you can get a handle to the references of each of those terminals then you should be able to call the "terminal" method via an invoke node "Connect Wire"

<a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/c912a99b-d6e7-4ed4-8452-1a5c4658c9a1/2009-06-19_1654.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/c912a99b-d6e7-4ed4-8452-1a5c4658c9a1/2009-06-19_1654.png" width="214" height="146" border="0" /></a>

Good Luck

~,~

Norm Kirchner

[swatts]

Thanks for you quick response Captain,

I want to drop 1 or more feed back nodes onto new block diagram and wire them through the case statement.

So far I've created a type Def enum and populated the case statement accordingly, the next step will be to allocate local memory and inputs and outputs.

I can't workout the correct reference to wire the internal tunnels together (like the tunnel-wiring wizard)

The idea is to have a front panel that looks like a component spec that generates fully populated, type def'd components.

It's so close I can taste it!

regards

Steve Watts