Test Bench Scripting Language

[tylerhollar]

Hi,

I am an intern at a company which is wanting me to create a scripting language and compiler that would be capable of controlling several instruments on their test bench through GPIB, as well as use the PXI-7833R to communicate to one of their devices over SPI.  I would consider myself an intermediate LabVIEW user that has never really worked with any type of VI which involved parsing scripts or the like.

Is there any application other than LabVIEW that would be more suited for this type of application.  I plan to have to use several dll's written in C++ to make things easier on myself, but I wasn't sure if I was trying to re-invent the wheel here or if there was something like this that had already been done that I could refer to. 

Any help that anyone can give on this subject would be greatly appreciated!  Thanks.

[Jarrod_S.]

Hope I don't point you completely in the wrong direction, but Python's a good scripting language that's well accepted. I believe I've heard of it being used before in similar situations.

One nice thing about it is that it has built-in modules for parsing its own source code which you can use. The parser module takes in python source code and gives you access to parse trees with information about the expressions. I really have no clue how easy it will be to use the parse tree data that gets returned, but I have a strong feeling parsing the string text and forming a parse tree is the hardest part of the whole exercise.

I'm by no means a Python guru, but hopefully the link above can get you started or at least indicate if this is at all fruitful. Hope this helps!

P.S. And of course another option is not to bother parsing all the stuff yourself, but instead write some sort of wrapper functions that do the communication in Python itself. You can the call Python scripts from LabVIEW in a variety of ways.


Message Edited by Jarrod S. on 06-05-2008 06:23 PM

[Soundar]

There are several Third Party ActiveX Spread tools available, that you can integrate with LabVIEW to create script writer front end. Microsoft Excel, Farpoint Spread,.. are some of the licensed Spreadsheet tools that can be used as ActiveX in LabVIEW. But you may need to write LabVIEW library to use those ActiveX functions in your application. With these kind of tools, its more easy to create and edit the scripts (Writing commands as per your own LV compiler).

Finally it gives the 2D array as output. All you need to do is take each row and execute in a state machine.

Though it is not a full script editor, it will minimize the syntax validation.

[Wiebe@CARYA]

When it comes to making compilers, Lex, Yacc, Flex and Bison are often
mentioned. They can build a c program structure when given a Backus-Naur
Form (google BNF) language specification.

I've read "Game Scripting Mastery", which explains binding to Phyton, Perl
and Lua. It also walks through a complete custom scripting language in an
understandable way. There are lot's of books on compiler theory, but most
of them are very dry.

If you make it from scratch, you might as well make it in LabVIEW, if you
are going to use it in LabVIEW. Making a realistic general purpose script
language won't be easy regardless the choice of language. If the language is
limited, it could be fairly easy.

Using an external scripting dll has some downsides. You'll have to push/pop
every variable manually, register functions, find some way to use callback
functions, etc. This is all easy if you use the language in C/C++, but some
are difficult in LabVIEW.

Next to the other languages recommended by the others, you might also
consider Lua (see LuaVIEW for a LabVIEW implementation).

Regards,

Wiebe.

[Dennis_Knutson]

Let's not overlook TestSTand. For instrument control, you have built-in steps for instruments with IVI drivers and it's pretty simple to creat your own custom test steps. It also inlcudes different report generators and database logging so you would not need to write that code yourself.

[tylerhollar]

Thank you all for responding so quickly, all of your help is very appreciated.  I will have to go through many of these languages to determine which option is going to be the best suited solution for this.  Other than TestStand and Python I really have not heard of any of the others.

I have brought up the idea of using TestStand to the team that is going to be primarily using this application and they have said that many of them have no experience at all with LabVIEW and don't really feel comfortable with the idea of using something like that to do this.  They all say that they would feel much more at home with a text based language that they can all pick up on easily.  Which, obviously creates more work for me because I have to be able to document all of this so that it is easily to manipulate by others...

I am looking into the LuaVIEW interface right now, I will definitely look into all of the others later and let you all know how things are progressing.  If anyone else has any other ideas for ways to make this easier I would greatly greatly appreciate it.

I have one more question which I will really just need once I get the parsing done.  As I said in my first post I will be using an FPGA for communicating with a device that will be constantly relaying information back from an A/D.  In order to conserve space on the FPGA I am thinking of somehow parsing the code in a way that the commands that only concern the GPIB instruments will be run from the host VI and the code for communcating with the device will be loaded onto the FPGA Target VI.  Does this sound like the best way to go about this and do you have any ideas for how to do the separation?

Thank you,
Tyler

[Dennis_Knutson]

As far as TestStand and LabVIEW, you do not have to use LabVIEW or any other language in order to create 'scripts'. You can download an evaluation version to see for yourself. On one side of a TestStand window are step types - specifically the built-in types like IVI, database, etc. Say a programmer created a new test type called 'InstrumentX'. The user could simply select InstrumentX and then with a single click, a window will popup that will give the user all of the options for setting up the instrument and taking a measurment. The user really doesn't have to learn any type of language. It would only require a single knowledgeable programmer to create the step types that an untrained person can use. Think of it as the equivalent of the Express VIs in LabVIEW. You hide all of the complexity behind a nice and simple GUI. At the last place I worked, I had several TestStand users but only a couple knew the first thing about LabVIEW.

There is of course more to TestStand than just that and a user will have to learn something about it but I don't think it would be nearly as hard as learning a whole programming lanuage such as PERL.

[tylerhollar]

Ok, I am going to try the evaluation version of TestStand out today and tomorrow and then let them come in and try to get a feel for it to see if that might actually be better.  When I was first given the project I had thought that TestStand may be the best way to go about it even though it is not really creating "scripts" but in reality it may give them more functionality and ease of use. 

Thanks for the recommendation, I will let you all know how it pans out.  I am still planning to look into some of the other languages as other ways to go.

[Wiebe@CARYA]

>I am an intern at a company which is wanting me to create a scripting
language and compiler that would be capable of controlling
several instruments on their test bench through GPIB, as well as use
the PXI-7833R to communicate to one of their devices over SPI.  I would
consider myself an intermediate LabVIEW user that has never really worked
with any type of VI which involved parsing scripts or the like.

TestStand would be good for the final goal ("test bench through GPIB, as
well as use the PXI-7833R"), but it won't forfill the assignment ("create a
scripting language and compiler").

Creating a scripting language and compiler is much more fun (= much more
work).

If you want to make a GPIB/PXI testbed system, and finish in a reasonable
time, TestStand is probably the way to go. Unless you want to distribute it
10-1000 (don't know the numbers) times, then the license fees will be higher
then the development time to make it yourself.

Tyler, you need to specify to us your goal better...

Regards,

Wiebe.

[tylerhollar]

Hey guys,

Sorry I guess I really haven't been too specific on the requirements for the project.  Honestly, the description given to me was pretty vague as well.  No one here is familiar with the capabilities of LabVIEW or TestStand which is why they are asking for some "sort" of scripting language which will give them the ability to create a variety of validation and characterization test sequences that can control all of the instruments on the bench and communicate with their device. 

I only have around 3 months to complete the project, so that is why I am rushing to try to get some sort of idea of the best way to go about this.  I understand what Wiebe is saying about it being a lot more fun (work)  to be able to create an entire language and compiler, which is what I would love to do, but I also want to be able to produce a working application by the end of this internship.

Also this will only need to be used on around 2 or 3 PC's at a maximum.  If that helps at all.

I guess now, knowing the timeframe and what is expected are there any new recommendations? 

Thanks for all of your help so far, this is very very helpful.

Tyler

Message Edited by tylerhollar on 06-06-2008 11:15 AM