[CR] Scripting Tools

[gb119]

View File

Scripting Tools

---

lava_lib_LabVIEW_API_scripting_tools v0.22.1.21 by University of Leeds

Author: Gavin Burnell

Copyright: Copyright © 2007-2010, University of Leeds

License: BSD

Compatible LabVIEW Versions: >= 8.6.

Compatible OS Versions: ALL.

Description:

This is a LabVIEW 8.6.1 Library of VIs to help with scripting.

The public VIs include routines to get hold of the block diagram references, control terminal references, get the connector pane reference and select the connector pane pattern and wire controls up to it. There are a number of routines to help wire the block diagram up, including creating a selection of the primitives (I got bored of coding them all up !).

I've stuck in some routines that work with tags - hidden away is the capability to tag LabVIEW vi-server objects with arbitary data. One possibility is to use this to identify bits of the block diagram of a vi for moving and rewiring via scripting.

The scripting Tools includes a separate XNode support library that provides routines to help scripting and terminal adaptation in XNodes.

There are some routines to help with undo transactions new to this release.

This Package Conflicts with these other packages:

LAVAG_scripting_tools >= 0.0

Scripting Tools >= 0.0

---

• Submitter
  gb119
• Submitted
  07/02/2009
• Category
  VI Scripting
• LabVIEW Version

[gb119]

Thanks to the LAVA team for resurrecting the Scripting Tools.

The latest version is available via subversion on the LAVACR repository on Google: http://code.google.com/p/lavacr/ including an 8.6.1 version. Future releases (as and when I get ownership of the CR entry back (!)) will be for LabVIEW 8.6.1 or higher versions only. With the release of LabVIEW scripting most of this code is now easily reproduced but hopefully some folks will still find it useful.

[Michael Aivaliotis]

Future releases (as and when I get ownership of the CR entry back (!))...

Hey Gavin, I transferred ownership to you. You should able to edit and update the submission.

[gb119]

I've just uploaded a new version - 0.20.1 which has several new features, including a vi that can create structures by enclosing objects that already exist on the block diagram - just like the regular draw structure around things does. There;s also a couple of vi's that do things that aren't exposed by scripting - like turning on the "use default if not wired flag" on tunnels and triggering type propagation. I've stuck these together to create a new example too - a pugin for the JKISoft RCF framework that will wrap everything in a case structure, wire up the error wires and then set the output tunnels to use default value if not wired (so the resulting VI does actually compile).

[gb119]

Uploaded a new build 0.20.02.6 which is now a VIPM Package (built with VIPM 2010). This doesn't add any new functionality, but does now install palettes properly into a LAVAG Category.

[gb119]

Version bump to 0.21 - new feature is a routine for finding the downstream sink terminals of a wire from an arbitary point close to one segment of the wire (e.g. to be used for working out where in a multi-branched wire a node needs to be inserted if the user clicked at a given co-ordinate)

[dannyt]

Version bump to 0.21 - new feature is a routine for finding the downstream sink terminals of a wire from an arbitary point close to one segment of the wire (e.g. to be used for working out where in a multi-branched wire a node needs to be inserted if the user clicked at a given co-ordinate)

I cannot get the latest version of scripting tools package to install in LabVIEW 2010. I am not sure if this is a package or a VIPM problem. I suspect it is a package issue at present and somehow involved with format release of scripting. Is there a way to find out what the auto-conflict is referring to ?

I will force the install and see what happens

EDIT unselected the auto-conflict and installed in 2010 but did not load as expected

Dannyt

[gb119]

I cannot get the latest version of scripting tools package to install in LabVIEW 2010. I am not sure if this is a package or a VIPM problem. I suspect it is a package issue at present and somehow involved with format release of scripting. Is there a way to find out what the auto-conflict is referring to ?

I will force the install and see what happens

EDIT unselected the auto-conflict and installed in 2010 but did not load as expected

Dannyt

Ok,

I've got another rebuild that installs cleanly (for me anyway) on LV2010 64bit. Unfortunately the Code Repository file uploader is being funny and not letting me upload the file right now.

Edit: Code Repository playing ball now. Version updated. Any reports problems installing on LabVIEW 2010 or 2009 happily accepted.

[dannyt]

Ok,

I've got another rebuild that installs cleanly (for me anyway) on LV2010 64bit. Unfortunately the Code Repository file uploader is being funny and not letting me upload the file right now.

Edit: Code Repository playing ball now. Version updated. Any reports problems installing on LabVIEW 2010 or 2009 happily accepted.

Hi Gavin,

That is great thank you, I can now load the package OK into LabVIEW 2010

[gb119]

I've released a new version (0.22.1) that cleans up a few bugs and adds a couple of features that I needed to help write XNodes based on a templating approach more easily and quickly. I'm currently working on converting OpenG Array tools to XNodes using this toolkit (which is why I've removed the dependency of Scripting Tools on OpenG array tools !) so that they are not limited to just the types for which polymorphs have been provided but will work with any suitable array type. There is an initial release out now.

[GregSands]

Hi Gavin --

It seems as though "Check Cluster Term Type" is missing its connector pane assignments.

Cheers ~ Greg

[gb119]

It seems as though "Check Cluster Term Type" is missing its connector pane assignments.

Cheers ~ Greg

Hmmm, oops. Thanks for spotting that - now fixed in 0.22.02.

Too much working too late at night methinks.

Gavin

[Bobillier]

Hi Gavin

I want propose you one small vi for your library. This Vi return the ConPane index on one control (connect to ConPane) if find.

Perhapse you can add it to your library.

Regards

Eric

Find Control Index in ConPane.vi

[gb119]

Hi Gavin

I want propose you one small vi for your library. This Vi return the ConPane index on one control (connect to ConPane) if find.

Perhapse you can add it to your library.

Regards

Eric

Nice.

Added to version 0.23.0 (after back saving to 8.6.1f2 and renaming Find ? to Found ? on the indicator label )

Gavin

[GregSands]

I think there are problems with the "Find tagged and replace" routine - the "Replacement Path" control does not default to a truly "Not a Path" value, and the "New VI Object Style" should be a Ring control (with the appropriate values) rather than an Enum. I've attached an 8.6 version of what I think should be the correct VI.

I also created a little utility which may be useful to add to your XNode support, though it is quite tailored to your own method for creating XNodes!

Find tagged and replace.vi

Copy+WireScript.vi

[gb119]

I think there are problems with the "Find tagged and replace" routine - the "Replacement Path" control does not default to a truly "Not a Path" value, and the "New VI Object Style" should be a Ring control (with the appropriate values) rather than an Enum. I've attached an 8.6 version of what I think should be the correct VI.

I also created a little utility which may be useful to add to your XNode support, though it is quite tailored to your own method for creating XNodes!

Thanks !

I've used your patched Find tagged and replace and added a new Copy and WireTagged Element which is essentially the same as yours except that I put the tagname and value to look for into a front panel control (with the defaults set for my standard tags). Uploaded as version 0.24

Keep the bug fixes and additions rolling folks and I'll merge them as and when I get time...

[GregSands]

This library is obviously not heavily used any more, as I've just noticed that the Build Array primitive routines both have the wrong object created.