LabVIEW Scripting Recorder / Generator

[Gregory]

Originally suggested by RavensFan.

LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them. 

[AristosQueue (NI)]

I once tried to code that. It is amazingly hard to do. Eventually, I did get something like it, which is how the automatic data mutation of LabVIEW classes works. I consider it to be the hardest code I have ever written in my life, bar none, and all it did was monitor for adding, removing, replacing, and reordering controls in a cluster!

But. I like to dream big, and I agree it would be extremely useful. So I'm adding my kudos.

[wiebe@CARYA]

I think one of the hardest things about this idea is the definition of the problem: how should this actually work?

E.g. if you click somewhere and do things, would the macro repeat at the exact same click, or on the current position? Once you start making things like this, you'll soon get a tree of choices and that tree with open ends would grow exponentially. Excel fixed some of those problems by making recorded macros editable.

It would be hard to make something that fits a certain situation, but to make this a general purpose solution would be near impossible (aka: sounds like fun).

Not sure if LabVIEW users have enough hooks to try this with just scripting and Windows API's. AQ: did your attempt used more then just that?

I'll kudo it anyway, because it would be neat.

[AristosQueue (NI)]

> AQ: did your attempt used more then just that?

I had full access to LabVIEW's internal code, the ability to intercept events at any level of abstraction I wanted, and deep knowledge of the entire source model of a VI. In short, I had about every advantage one can think to have. 🙂 Trying to figure out what was semantically significant about a given mouse click was hard. Deciding when to generalize from "this Add node" to "a generic node" vs "any Add node" vs "any terminal on any node" was hard. And all of that was just the recording of the actions. I never got as far as actually scripting the scripting code. I only spent a couple weeks of spare time on it before deciding it was too large a scope project for one person to tackle, at least as a spare time project.

[kosist90]

There could be another point of view at this task. Imagine having not recorder, but generator of generator of the code, based on template. I mean, if one has some VI, he could specify it as source VI for generator, and the generator will generate code (another generator), which will generate exactly the same VI, as the souce VI. In a manner, like it would generate this VI from the scratch, and not just copying nodes from one VI to another. And the user could edit this generator in any way he wants, and then use it for his purposes.
Of course, for editing generator should generate code in some reasonable way, so user could edit it. For example, as a simple state machine pattern, going node-by-node creation, then wiring, etc.
It could be "easier" to implement, because you could specify exact rules, by which VI will be generated, and there is no such big tree of choices for actions, as in case of "macros" recording.

[wiebe@CARYA]

That would be a lot of work. What would it effectively offer?

You make a VI, and then a VI that can recreate the VI. What would that give me more then a simply copy of the VI? In other words, why would I want to create a script, then edit the script, only to recreate a VI. I might as well simply edit the VI and save it or use it?

We have VI's (somewhere) that can recreate any VI (including itself) node by node. Making a script to store the information as an in between language is just an extra step. But I don't really see the point.

The hole point of recording would be that you can actually do things with excising code.

[kosist90]

Of course point is not to recreate the same VI. Point is to create similar VIs based on this one. Imagine, that you have some configuration classes, and you'd like to create user interface for them. For each class - separate UI. In case if I'd have such generator, I'd prepare UI for one of classes, then get generator of this UI, and modify it in the way, that: I set input configuration class, get its private data, and pass it as parameter to generated generator. And generator (after small modifications) would be able to take this data as input, and create UI with proper control types, names, etc.
And if I need 2-3 such UIs, scripting would be overhead. If I need 10 UIs, scripting could be efficient.
Now I prepare scripts for classes creation - with main methods + unit tests. Copying and modifying VIs require more time, than script creation, and its usage. And such tool could simplify the procedure.
So such generator could prepare heavy base for scripting, and user could modify its small part, to generate VIs with the similar, but different content but by the same logic.

[wiebe@CARYA]

Ok. So if the generated script is scriptable (guess XML or plain text would do), it would add some value. I know at some point NI at least looked into this (there are traces of it), but I think it's just very difficult. A good scripting API wrapper would make it easer, but again it would be a lot of work.

[AristosQueue (NI)]

> . So if the generated script is scriptable (guess XML or plain text would do)

I believe the point of kosist90's suggestion was to generate the G scripting code.

[kosist90]

Exactly - generate scripting VI, and then edit it as one wishes.

Currently available scripting wrappers (from LAVA) are great and awesome, but there is no any other (or at least I haven't seen it) useful templates for generation of multiple-nodes VIs in some nice manner... But that's why scripting is advanced topic, though ))

[wiebe@CARYA]

Ah, ok. Not too much apart. I'd prefer a text medium, but scripting a VI script would work. Once you have a command pattern to execute a (loaded) script, it's not hard to make it generate the script, as long as there's a 1-1- match. I've done this for formula's (going from text to command pattern to generated code). Even supporting both would be not that much harder, compared to the total workload. Either way, it would be challenging to automate making scripts that work in a natural way, convenient for humans.