BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Scripting History

To be honest I thought about posting this at the LabVIEW sub-forum, but the topic is more curiosity than anything else, and I didn't want to clutter that forum when this one is sorta dedicated to curiosity, among other things.

 

So I was thinking about this the other night.  LabVIEW Scripting is one of my favorite features of LabVIEW.  The fact that I can write code, in a graphical language, and that code can generate code in that graphical language, is facinating to me.  Bad example but I can't write a PowerPoint presentation that makes PowerPoint presentations.  Which made me wonder, how early was Scripting used?  And how early was it planned to be a feature of LabVIEW?

 

I know that scripting existed in some semi-public form in LabVIEW 7 era.  At the time NI gave out to select partners that needed scripting functionality, the ability to use it, it was incomplete, and undocumented.  But what is the earliest example of NI using scripting publicly, or experimentally?

 

It just seems that a lot of work has to go into a thing like Scripting, and I'm sure R&D worked on it for many years.  So was it a feature NI planned from since version 1.0?  Or was it planned from 3.x where there were massive changes?  Or planned from 5.x where there were even more massive changes?  Any history of Scripting or insite is appreciated.

Message 1 of 14
(14,649 Views)

Not wanting to be pedantic or anything (yeah, right, Like that would ever happen).....

 

You CAN write macros in a Powerpoint document which can create presentations.

0 Kudos
Message 2 of 14
(14,643 Views)

@Intaris wrote:

Not wanting to be pedantic or anything (yeah, right, Like that would ever happen).....

 

You CAN write macros in a Powerpoint document which can create presentations.


You are welcome to be pedantic.  I'm sure you understood my intention.  I was refering to the graphical portion of PowerPoint.  Can I make slides, that produce slides by interacting with the graphical portion of PowerPoint.  Using the graphical tools.  Now that stipulation is a difficult one to define because LabVIEW has some text components (like MathScript) and drawing the line is hard to do.  So I guess what I'm trying to say is no matter how I phrase my amazement, someone will be able to say, other programs do similar stuff.  But none I know do it as well, work with such a large set of features, as LabVIEW.  I mean there are things I can do with my mouse and keyboard, that I can't do with Scripting yet.

0 Kudos
Message 3 of 14
(14,641 Views)

I believe scripting was first used in LabVIEW 6.0 for work on the State Diagram Toolkit. I am not aware of any scripting features in 5.1 or earlier.

Message 4 of 14
(14,636 Views)

One of the first public uses of scripting (outside the LabVIEW team) was Vision Assistant, based on LabVIEW 6.0 code. It was followed by the Motion Assistant, then a plethora of other Assistants. Motion Assistant used the first version of what is now the codegen engine, a template based scripting engine which hides much of the complexity of scripting from the user.  LabVIEW 7 introduced ExpressVIs, which used scripting under the hood. Note that none of this allowed users to directly use scripting. It was a bit on the raw side. Now, both scripting and the codegen engine are available for anyone to use.

Message 5 of 14
(14,630 Views)

While I have to lean toward DF's reply about the Vision Assistant as a historical interst is the State Diagram Tool kit that Darren mentioned I think was important.

 

The first version of that toolkit did not password protect one of the components and with a little poking it could be opened up to find scripting nodes and thh obiquitous "Traverse..." that finds stuff.

 

Go back and search LAVA for neBulus asking about magic beans. At that time only one person took me up on the offer.

 

I believe it was then up to Norm to get hacky and expose more.

 

Ben

 

See the traverse saved as 8.2

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 14
(14,614 Views)

@Ben wrote:

 

Go back and search LAVA for neBulus asking about magic beans. At that time only one person took me up on the offer.


Here is the thread by the way.

 

That is a very fun concept to think about, even in todays world where NI has generally opened up a lot of functionality, in terms of scripting.  And generally I think the use of passworded VIs has gone down within VI.lib.

 

I think it is fun to think about partially because back then while those features were locked away, you know you were very close to having them.  Just on the other side of this password protected front panel, you knew was some fun tool that a simple string password would allow you to see.  For better or worst I don't think something like that exists in LabVIEW echosystem today.  If I said you had three LabVIEW features that would magically be added, the appeal isn't there.  I think it was knowing that the features already existed, and you simply needed the key.

 

Thanks for the input guys.  So is there anyone that can say when Scripting was first planned at NI?  My money is in 3.x discussions were had, and in 4.x work started, and 6.x use of it was stable internally.

Message 7 of 14
(14,604 Views)

Scripting was originally a hack to leverage the GUI development environment from VI server, I believe done in LabVIEW 5.1. To this day, if you want to figure out how to do something in scripting, the easiest way is to do it in the dev environment, then translate that to code. It is not perfect, but it does work most of the time. In the early days, this was an almost direct translation. Enough so that if you had an object hidden behind another object, you could not select it. The first few releases were also missing such things as delete and replace. Things gradually improved over time until scripting was officially released. 6.x was definitely not stable Smiley Frustrated.

0 Kudos
Message 8 of 14
(14,599 Views)

@DFGray wrote:

 To this day, if you want to figure out how to do something in scripting, the easiest way is to do it in the dev environment, then translate that to code.


 


Something that I think would be cool to have is something like the Excel Macro Recorder.  Where you do something manually, but the application is in the background translating that to code for you.  Then when you've stopped recording, you can go and look at it.  It often isn't the cleanest.. I usually do a lot of editing to make it more concise, and add the loops and case statements needed to do the programmatic, repetitive stuff that I'm trying to automate.  But you have a headstart because the key parts of the code, the methods and properties you know exist but don't know how you'd find them, are now in place.  If excel had a "Script Recorder", whatever you do while it is running is lays down the appropriate methods, properties and wires in a separate blank VI.

 

It seems like it would be a lot of development effort to program something like that, and I don't use scripting often enough that it would be a huge help to me, but it would be cool if it existed.

Message 9 of 14
(14,583 Views)

RavensFan wrote:


Something that I think would be cool to have is something like the Excel Macro Recorder.  Where you do something manually, but the application is in the background translating that to code for you.  

 

It seems like it would be a lot of development effort to program something like that, and I don't use scripting often enough that it would be a huge help to me, but it would be cool if it existed.


Oh I had forgotten about that feature, which I used all the time.  One issue you find doing that, is the steps you perform aren't always translated the way you expect.  Like I may want to select the workbook named "My Workbook".  So turn on recording and select that workbook.  Looking at the VBA recorded it might not say it selected "My Workbook" but instead it may say it selected the second workbook in the document.  I'd assume if LabVIEW had a recording feature it would have similar limitations, where it would produce the exact code you did, but maybe not the way you wanted.

 

Still I think this is a fantastic idea that should be on the idea exchange board.  But to be honest I never expect it to be a supported feature.  It sounds like too large of a task.  Scripting at times can be confusing knowing what is possible and how.  This would take away some of that confusion by showing code that did what the user did.

0 Kudos
Message 10 of 14
(14,577 Views)