any VIs that can execute a text-based language within LabVIEW

[MattI]

Has anyone ever developed a VI that can execute a typical (i.e., C or C-like) text-based language from within LabVIEW?

I want something really cool & dynamic/powerful, not just "Formula Node" (no put-down intended, "Formula Node" is fine for some stuff).

That is, a VI that can take a program (i.e., read it in like any file), parse its elements & construction (flow), & adapt the language elements to LabVIEW, and then execute it but using LabVIEW structures instead of the flow control in the textual program, and using VI calls instead of function calls, etc.?

It seems like it might be do-able, as long as the function list had a 1:1 mapping to VIs, and the flow control elements in the language were rather limited (well, they always are).

Just curious & wanted to ask before I get too serious on this.

(Seems like case statements that match the string/name of the function with the equivalent LabVIEW structure within the case might work, but I don't know how to handle nested flow control, except maybe to call subVIs.  But this makes function calls tricky cuz then they need to execute within the subVIs?? -- hmm.)

I've developed some code already but not into it enough to really know how tough it will be.  Thought I should ask first.

-- Matt

[altenbach]

If you have LabVIEW 8.0 or higher, have a look at the Mathscript window. It can load and execute files having matlab-like syntax.

[chilly_charly]

You are talking about the development of an interpreter. Except if there was really good reasons for that and if the number of functions to be interpreted was very small, I would not undertake such a tremendous work.

Basically, you would need to read each program line and use a state machine to decode each command. Execution will be extremelly slow.

C like programs can be written directly in a formula node (may be you missed the fact that programming structures such as DO, FOR and WHILE loops can be used there ?)

If this is just for the fun, I'm sure you'll find something more usefull to do 😉

If you are in lack of inspiration, just ask here and you'll receive thousand of programming ideas 😄

Otherwise, start to decode something really basic such as

For i = a to b step 0.1

 c = i *b + c (to be replaced by any function of a few input variables)

Next i

Message Edité par chilly charly le 09-17-2006 05:56 PM

[tst]

Here and here are a couple of links you might want to check out. Haven't tried them myself, though.

Of course, that's execution and not conversion (something which you seemed to suggest as well). You can do conversion using VI scripting, but as mentioned, you will have to write it yourself and it's probably not worth it. Check out the LAVA forums for their scripting board.

[Wiebe@CARYA]

Hi,


We've written a parser that reads a formula (ax+b), and calculates the result. In a way that's a program that is executed. An interpreter should be able to do at least this, because it might apear in the program. I know NI has vi's for this, but we needed a more flexibility (integration with our databus, and adding our own functions, changing formulas during runtime).


What you want to make is a way to execute a script. There are some good books on scripting, but all based on c++ (as "host" language). Most profesional games use some sort of scripting to allow modifications without recompiling, other use it to add plugins. To make something like this in LabVIEW would be fun (=very difficult). But since LabVIEW executables can run vi's, why not make plugins in LabVIEW?


You might also consider to interface with existing scripting languages. Phyton, Perl, Lua, TinyC, Tcl, all have API's to offer programs their power. You'll still have to make an interface, and have to find some way to handle callbacks and other text language specifics, but it will be easier then (re)inventing a language.


Someone might already done this for some of these languages...


Regards,


Wiebe.



"MattI" <x@no.email> wrote in message news:1158369006698-416790@exchange.ni.com...
Has anyone ever developed a VI that can execute a typical (i.e., C or C-like)&nbsp;text-based language from within LabVIEW?
&nbsp;
I want something really cool &amp; dynamic/powerful, not just "Formula Node" (no put-down intended, "Formula Node" is&nbsp;fine for some stuff).
&nbsp;
That is, a VI that can take a program (i.e., read it in like any file), parse its elements &amp; construction (flow),&nbsp;&amp; adapt the language elements to LabVIEW, and then execute it but using LabVIEW structures instead of the flow control in the textual program, and using VI calls instead of function calls, etc.?
&nbsp;
It seems like it might be do-able, as long as the function list had a 1:1 mapping to VIs, and the flow control elements in the language were rather limited (well, they always are).
&nbsp;
Just curious &amp; wanted to ask before I get too serious on this.
&nbsp;
(Seems like case statements that match the&nbsp;string/name of the function&nbsp;with the equivalent LabVIEW structure within the case&nbsp;might work, but I don't know how to handle nested flow control, except maybe to call subVIs.&nbsp;&nbsp;But this makes function calls tricky cuz then they need to execute within the subVIs?? -- hmm.)
&nbsp;
I've developed some code already but not into it enough to really know how tough it will be.&nbsp; Thought I should ask first.
&nbsp;
-- Matt

[shoneill]

What I recommend is having a look at the "Advanced formula parsing" VIs shipped with some versions of LV.

Bear in mind this it an interpreter to run single equations with variables and so on.

Have a look at the code, and analyse the extent to which it is neccessary to interpret the easiest of code (No nesting here, no loops, no case structures!).

I think this should answer your question as to whether something like this is feasible.

The "LEV-MAR" optimisation routine in LV uses this code, but when I replaced the forumula parsing with custom LV code, it ran so much faster, I thought something was wrong..... 🙂

In other words, the complexity of such an undertaking is immense.  Truly many man-months if not years of work.  Add to this the fact that it won't be very fast and it seems like a non-starter.

Unless someone else knows something I don't.

Shane.

[Kevin_Price]

A lot depends on the scope of what you're after.  A full-up interpreter for a bona-fide programming language is not something I'd care to tackle.  However, I've done a few different medium-sized projects that supported a very limited text-based scripting language which proved to be VERY useful in "handing off" the project for use by non-programmers.

First you pick the script-language instructions to support and define some syntax.  Resist the temptation to get super clever with your syntax -- simpler is almost always better.  I've found the "Find Token" string function to be very helpful to get the parsing started.  I also will typically convert my text to all lowercase before any parsing is performed.  Each individual script instruction can map to the LabVIEW vi capable of performing that instruction.

For example, suppose you're testing some digital camera imaging sensor.  You have a controllable filter that can be set to allow purely Red, Green, or Blue light to pass through.  Maybe also a White and Black position to allow or stop all light.  You can also control your light intensity.  Here are some possible script instructions to support:

"Filter <color>"  - will cause filter to move into the specified position

"Intensity <0-100>" - sets an intensity level of the light source from 0 - 100% of capability

"Snap" - will cause a frame grabber to capture and store an image, with filename based on filter and intensity settings

"Wait <delay time>" - don't know how it fits here, but I always need to implement a pure delay in my tests

"User <text message>" - brings up a little dialog prompt requiring user intervention before proceeding to next step

Now you've given a user a little set of tinkertoy commands that they can build up however they wish.  All this script parsing may seem like overkill on day 1 when they are merely cycling: Intenstity 10, Filter Red, Snap, Filter Green, Snap, Filter Blue, Snap, Intensity 20, ...  But what about the day where the investigator says, "Hmmm, I wonder if the Green sensors are affected by overexposure to Red light, and how long does that effect last?"  Well, they can go: Filter Red, Intensity 80, Wait 25, Filter Green, Snap, Filter Black, Intensity 0, Wait 25, Filter Red, Intensity 80, Wait 10, Filter Green, Snap, ...

Already, with a very few very simple script instructions, it's possible to poke and prod at some modestly complicated questions.

Nested Flow Control: this is more advanced, but not beyond reason.  I modeled an interpreter after what I think I know about simple microcontrollers.  Script execution used a "program counter" to indicate which instruction is to be executed next, and I used LabVIEW queues in stack mode (Last In - First Out) to store the program counter while handling flow-control instructions like subroutine call/return and loops.  I also used a queue in stack mode to store my Loop iteration values.  Stacks make it natural to support nested loops.

-Kevin P.

[MattI]

You pretty much hit the nail on the head w/ what the purpose is, and the scope of it.

There's only a half-dozen flow-control statements I'm going to encounter, so it doesn't seem that bad to me.

Agree w/ others in the thread that it might be really tough to do a full-blown interpreter.  I'm not looking to do that, but rather just write one that will get me by for 90% of the situations I'll get w/ the users.  For example, using a single For loop to do something repetitively; at worst, the condition-statement changes (quite like Kevin Price) described.

As you suggested, I was also thinking of using a "stack" approach to keep track of where I'm at w.r.t. the control statements.  I was thinking that a cluster could hold the ctrl-type, condition-statement (maybe the Advanced Formula Parsing suggested by shoneill/Shane will work here; it was handy for me when working w/ Lev-Mar curve fitting, too!), and the current-condition.  I figure there's just a

Fit the big case statements (one for all the functions on Frame 0, one for all the flow-control statements in the next Frame) inside a while loop & keep a back door to be able to abort!

I agree with & thank all others for their suggestions, including chilly charly for his suggestion to start w/ something basic.

You guys are all obviously very sharp & very helpful.

Note: I don't care about exec time much; I'm talking to the unit-under-test / UUT at 9600 baud, so a little overhead is no biggie!

-- Matt I. / matti

[Wiebe@CARYA]

Hi,


It could be fast... But the code has to be "compiled" to some intermediate language. Java does this (, with a just in time compiler), and so does .net (by compiling before executing). Lua and other scripting languages have such a system, the text code is compiled to byte code. A virtual machine then executes it, making it a lot faster (compare old basic versions with new versions, the old versions interpreted, the new versions compile first).


On of the reasons I created my formula parser, was because the standard vi's did to much (, and where to slow because of that). They solve formulas (e.g. 3y=4x+6), where I just needed to evaluate (5+6*(mod(2,4)). With a link to a global databus I can write (in an external text file): USER1 = max(poly(PIT110,1,2),poly(PIT120,1,2)), where "USER1 = " is only used to store the result, not to solve anything.


I thought about building in cases, switches and loops, but didn't see an immediate need. I think the parsing of any formula is more difficult then the loops etc.


The "undertaking" of making a language parser won't be years, if you limit yourself. Don't implement classes. Don't implement functions with variable number of inputs. Don't implement namespaces. Don't try to make it "strong typed" (or do, I don't know what's more difficult).


If you consider + to be a function: "c=add(a,b)" the parsing is much easier then allowing "c=a+b".


Or rather: try to get calculations, functions, simple flow directives and simple variables working. Still going to be a few months work. Then try external files, preprocessing, structures, etc.


Btw. google "LuaVIEW". You'll find our con-colleagues website.


Regards,


Wiebe.





"shoneill" <x@no.email> wrote in message news:1158585007790-417036@exchange.ni.com...
What I recommend is having a look at the "Advanced formula parsing" VIs shipped with some versions of LV. Bear in mind this it an interpreter to run single equations with variables and so on.Have a look at the code, and analyse the extent to which it is neccessary to interpret the easiest of code (No nesting here, no loops, no case structures!).I think this should answer your question as to whether something like this is feasible.The "LEV-MAR" optimisation routine in LV uses this code, but when I replaced the forumula parsing with custom LV code, it ran so much faster, I thought something was wrong..... :)In other words, the complexity of such an undertaking is immense.&nbsp; Truly many man-months if not years of work.&nbsp; Add to this the fact that it won't be very fast and it seems like a non-starter.Unless someone else knows something I don't.Shane.

[Odd_Modem]

Knuth talks about a formula parser in one of his books in the first set. He develops an example solution in his pseudocode, based on the tree structure of the formula. Basically, the parser inputs symbols and classifies them until a rule is matched, then it is reduced to a simpler form. Yacc and Flex are the Unix tools that do this work, and it is much easier to use these than to write it out explicitly in LabVIEW. That said, I have a Common LISP (subset) parser, of sorts, written entirely in LabVIEW, in order to practice using (or abusing) a stack. I found that it was most useful to reduce expressions to truth values (either true or false) and this allowed arbitrary expressions to be used as loop control expressions and such.

Message Edited by Odd_Modem on 09-19-2006 06:25 AM