LabPython and LuaVIEW revisited

[viSci]

Greetings All,

I am hoping to generate some discussion on the relative merits of these 2 scripting interfaces. I am currently using LuaVIEW and have had some good success with it to model pumping mechanisms for a medical device. I am somewhat concerned about the use of a proprietary CIN and some undocumented vi server methods (set/get tag) that LuaVIEW depends on, since we would like to settle on a tool that we will be able to standardize on for the long term use within our R&D. I am also concerned about the scalability from the simple uses I am doing now to much larger prototyping of complete medical devices that would involve the deployment of a large hierarchy of script modules.

Mike Sachs

Intelligent Systems

[Phillip Brooks]

You didn't mention which platform you were running on, I'll assume Windows....

Your scripting needs reminded me of a BLOG post by Brian Tyler. He gave an example of using the LabVIEW .NET interface with something called IronPython.

This technique might be more open than using the CINs you describe, and would conceivably be more scalable/stable considering the larger user base that .NET type tools target. If nothing else, it might be an interesting read

[Albert-Jan Brouwer]

I am hoping to generate some discussion on the relative merits of these 2 scripting interfaces.

They're not comparable. The idea of scripting is to simplify

programming by making functionality available for calling from a

relatively easy and flexible interpreted language (a scripting

language).

LuaVIEW allows Lua to call LabVIEW: it is for scripting LabVIEW

code. LabPython allows LabVIEW to call Python, which is

the reverse of scripting: calling something interpreted

from compiled code.

I am somewhat concerned about the use of a proprietary CIN

The C code making up the Lua language and most of its

C-based interface to LabVIEW must reside in a CIN or DLL

for it to run as part of the LabVIEW runtime. No way of

getting around that other than a separate runtime,

with all the resulting integration issues.

Only NI could do better by statically linking a scripting

language into the LabVIEW runtime. Indeed, I wonder

why NI has not done so: LabVIEW has been rather

stagnant, as a language (I'm not talking the libraries,

drivers, or development environment here), so

adding a scripting language would be a quick means

of getting with the times.

[crelf]

Whilst not completely on topic, nor completely off topic, here's a link to Software Engineering Radio's episode on Scripting Languages. Althought the topics they cover are quite advanced, they are also general in nature and provide some great foundation knowledge of software engineering in a general sense (there's a good episode on error handling there too) - thanks to Jim Kring for suggesting se-radio to me a few motnhs ago...

[Jim Kring]

Chris: Glad you like the se-radio.net podcasts -- I'm enjoying them too.

Mike: Regarding, calling LabVIEW from Python, here is some example code that I through together a quite while back.

Cheers,

[jzoller]

Only NI could do better by statically linking a scripting

language into the LabVIEW runtime. Indeed, I wonder

why NI has not done so: LabVIEW has been rather

stagnant, as a language (I'm not talking the libraries,

drivers, or development environment here), so

adding a scripting language would be a quick means

of getting with the times.

If anyone has insight into this subject, I would love to see it.

Lack of market?

Competition with existing products (TestStand)?

Licensing issues with existing scripting languages?

The idea that everything in LV *must* be in G?

There's a scripting package in the works?

Unseen technical impossibilites?

None of these seem likely enough to actually be the reason. Perhaps NI will enlighten us someday.

Joe Z.

[Phillip Brooks]

TestStand experiences/observations

Competition with existing products (TestStand)?

The idea that everything in LV *must* be in G?

There's a scripting package in the works / Unseen technical impossibilites?

Now I understand Mike's question better. I thought the goal was to run scripts from within LabVIEW, not to use scripts to execute LabVIEW

I've had the priviledge to work with some guys who taught me much of what I know about LabVIEW. The last project we worked together on involved a lot of "families" of products with similar test requirements. Their decision was to deploy TestStand (then 1.0). The family of products was well suited to this type of test development. My part of the project was to write a LabVIEW ADO wrapper (before the DBC toolkit was available) and to create some TestStand sequences to look up instrument info in a database. The VIs would update TestStand globals that were referenced in other sequences.

I haven't used TestStand since then, but on a recent visit with these same people, I saw their newest TestStand implementation (using 3.5). I was impressed with the capabilities of TestStand, and what these guys had done with it, but at the same time was suprised at how much of the coding was actually done in TestStand.

OK, who cares? These are my observations:

Competition with existing products (TestStand)? TestStand is much more than a scripting language. The price and licensing costs should be proof enough! TestStand is great, but the current version is overkill for what 80% of an average LabVIEW user might want. With such a large investment in TestStand, I wouldn't expect NI to release something that would hurt this product's sales.

The idea that everything in LV *must* be in G? This was what suprised me with my friends. It appeared LabVIEW was more of a a wrapper for instrument control and a few complex calculations. There was very little G programming from what I saw (I may be wrong). I would rather spend my day writing G code than checking pre-and post condition actions and checking the spelling of sequence and station global references.

There's a scripting package in the works / Unseen technical impossibilites? I was reading the other day about changes to the type descriptors in LV 8 (now 32 bit). Maybe this change will somehow overcome technical difficulties or make support of a scripting package possible?

The learning curve for TestStand is STEEP. Just ask someone who has used TestStand about modifying the "Process Model" :thumbdown: If you want to do some general scripting, TestStand is NOT for you. Up until recently, the sequences could not even be protected. Anyone with TestStand could make a change to the sequence. I think 3.5 now includes some form of password protection.

What might be nice? A version of TestStand that would only sequence LabVIEW functions, and that would be part of the Professional edition of LabVIEW. The run-time for this version should be free. :beer: Maybe this could spur TestStand sales for NI? LV programmers could use this and learn it's potential and then justify the cost of buying the full package.

What are the options? As Joe pointed out, perhaps NI will enlighten us some day. Otherwise, we'll have to make due with third party tools, ActiveX and .NET interfaces.

[crelf]

What might be nice? A version of TestStand that would only sequence LabVIEW functions...

I know I'm chiming in late on this, but I can't agree more - I could sooooooooooo use something like this! I can't count how many times I've seen LabVIEW developers create their own "TestStand Lite" to do simple sequencing, only to fall on their faces when they need to do anything remotely complex or really reusable. I think that a real NI-produced "TestStand Lite" would be an excellent conduit to get current LabVIEW programmers into TestStand! :thumbup: Anyone from NI like to comment? Pleeeeeeeeeeeeeeease?!?

[viSci]

Teststand Lite, that would be an excellent idea. It also makes me wonder what happened to the promising OSTE that was abandoned on SourceForge. I myself use a rewritten Table based version of the original NI Test Executive for basic sequencing and a 'Test Manager' API for managing excel based test specifications, results and report generation. I am looking into creating a new version that would have a better test sequencing API with extended features such as subtests, vi template based parameter editing, script variables and conditional looping. Personally I would rather just buy a 'TestStand Lite' if it was under $1000 with free run-times if using NI hardware.

[Ale914]

QUOTE(sachsm @ Feb 2 2007, 12:22 PM)

Teststand Lite, that would be an excellent idea. It also makes me wonder what happened to the promising OSTE that was abandoned on SourceForge. I myself use a rewritten Table based version of the original NI Test Executive for basic sequencing and a 'Test Manager' API for managing excel based test specifications, results and report generation. I am looking into creating a new version that would have a better test sequencing API with extended features such as subtests, vi template based parameter editing, script variables and conditional looping. Personally I would rather just buy a 'TestStand Lite' if it was under $1000 with free run-times if using NI hardware.

I agree, a Teststand Lite is a great idea and OSTE was a good candidate to became a smart test manager, any possibilities to restar the work on OSTE?

I could put all my experience on LUA to build up OSTE.

Ciao

[Mike Ashe]

QUOTE(Ale914 @ Feb 16 2007, 03:03 PM)

I agree, a Teststand Lite is a great idea and OSTE was a good candidate to became a smart test manager, any possibilities to restar the work on OSTE?

I could put all my experience on LUA to build up OSTE.

Ciao

OSTE isn't dead, but it has been delayed numerous times, as you and others have noted. One of the reasons it was put off a while back was due to some of the "Authorized Application" licensing and non compete issues in the LV 7.x license. Since these have been resolved in 8.2 I'll have to see what I can do to get what I have ready for further development and finally let others in on development.

There were also some patent issues, but those have also recently been resolved.

OSTE's basic premise has always been to capture the front panel of a VI and then play that back, essentially sequencing VIs. Give me a private message if you want to be in the development.

[robijn]

QUOTE(Mike Ashe @ Feb 16 2007, 09:37 PM)

OSTE's basic premise has always been to capture the front panel of a VI and then play that back, essentially sequencing VIs. Give me a private message if you want to be in the development.

That sounds like an very useful and well implementable concept. It's a pity there's completely nothing on the sf website, I was interested to see more of it. If it's just restoring a front panel it's a piece of cake. But I'm affraid you also want to be able to build loops, conditions etc... What are OSTE's full requirements ?

QUOTE(Mike Ashe @ Feb 16 2007, 09:37 PM)

There were also some patent issues, but those have also recently been resolved.

In Europe software patents cannot be filed nor defended (officially, that is) so this is no problem for me to participate. I am strongly against software patents as they hinder innovation (and me) and are not needed at all (copyrights...).

Joris

[Mike Ashe]

QUOTE(robijn @ Feb 19 2007, 04:08 AM)

...If it's just restoring a front panel it's a piece of cake. But I'm afraid you also want to be able to build loops, conditions etc... What are OSTE's full requirements ?

MIKE: Yep, we have loops, simple branches, inputs from operators, database queries, and a bunch of other step types. OSTE's design also separates between the data acquisition and the later analysis/evaluation of the data. Sure you can still write a complete test in a single VI, but the design encourages separation of those two. Why? to allow modularization of acquisition and analysis into reusable (and resellable) components. More on all the requirements will come on first beta, but it's not ready yet.

In Europe software patents cannot be filed nor defended (officially, that is) so this is no problem for me to participate. I am strongly against software patents as they hinder innovation (and me) and are not needed at all (copyrights...).

MIKE: I would tend to agree, sometimes... I don't want to say more. Softwre patents can actually be a good thing if they are for truly original, innovative techniques, but lets face it, most are not. Some patents are granted for things that are so obvious as to make you want to scream. If you think it's bad in software patents, bio-technology is now worse. Look down at your hand, about 20% of the DNA you "see" is patented.

Sorry for getting on a non-LabVIEW rant there

[Phillip Brooks]

There is a thread on the 'dark side' that discusses TestStand Lite. An NI member opened up the discussion to ask others what they think TestStand Lite would be.

http://forums.ni.com/ni/board/message?boar...essage.id=23304

Since NI has added the ability to perform toolkit licensing checks from with LabVIEW, this might be a good time to revisit the idea.