Re : Re: CAN I use scripts to execute/command an automatic test with Labview?

[smercurio_fc]

No, you would not create the state machine in the XML file. That makes no sense. The XML file is for definining the list of actions you want to take. The state machine is in LabVIEW to execute the actions in the order that they are defined.

Nobody is telling you to use the LabVIEW XML schema. What you use is up to you. A schema tells you how to format the document. The LabVIEW XML schema is a format. There's an infinite number of schemas since they are literally user-defined. 

You haven't really specified what information you need to have in this file. It may very well be that you don't even need an XML file. I have a test executive that executes tests with an associated list of parameters. The list of tests and their associated parameters are in a simple text file. 

[leo2b]

I have just start since yesterday to look at the XML files I have nerver used it, I want to do test on a motor, so I have Programed some VI in Labview to generate DC voltage, acquire DC voltage, receive/transmit CAN frames, but all people that will use my program don't use necessary labview so I search a mean to program a test with a kind of script (XML, etc...), and labviiew will execute this script to generate a test (create a state machine and put the VI in function of my script).

This is the ideal thing, I search the better way to use only a .exe of a labview program with a modifiable script wich command it, my aim is that people don't need to change the diagram of my program in labview because they don't know how do that. I want they modified some parameters or tests in an other file... I know it's bizarre...

[Joe_H]

No its not bizzar, in fact it is a common occurence. the problem is that you are new to LV and need to learn a few things. Learn how to do state machines in LV. Then learn how to read in a file and parse it to get the info that you. Then use the info from the file to drive the states of the state machine. Do not worry about getting all fanvy with XML and other file types, just start out using a plain old text file and get that to work first and then progress from there.

[j_osh_o]

I agree that what you are doing is not bizarre, it is very common in my experience.  I think you need to do the following:

1) What specific actions does the test need to do? This will define the states in your state machine (please look up examples for state machine if you have not already done so)

2) For each action, what input parameters are required?  This will define your parameter list that will accompany each action.

You will probably want a producer-consumer state machine where the producer is reading the file and adding commands to a queue, and then your consumer loop will perform the actions.

Personally, I love XML.  It allows you to make a flexible hierarchy that you can extend indefinitely. With CSV you can be more constrained as to what parameters you can change without breaking the code.  That said, most engineer types prefer CSV, while XML is more common among software programmer types.

To avoid taking on too much at once, I would recommend using CSV (simple comma separated text file with each command on its own line).  But I encourage you to learn to use the LabVIEW xml parser and how to read and write data from XML files.

[leo2b]

Hello,

Thank you for your advices, I am new in LV but I have learn how to create a state-machine, I have all my states with differents parameters.

Now I will learn how to use XML files, CSV files or SYLK files to gives attributes to my states to choose the best language that I will use.

So if you have some informations about queued messages I will take it :-).

Best regards.

leo

[Spectre_Dave]

Since you are new to LabVIEW you should get your program working WITHOUT worrying about trying to get fancy and created a programmable State Machine.  I have been writing LabVIEW code for 20 Years and I took baby steps along the way.  I started out using flat sequences and then started using State Machines in the LabVieW 3-4 time frame, then event structure, Queued State Machines, Programmable Queued Message Handlers, etc. 

You should understand LabVIEW basics the move on to more advanced techniques.

We all started with the basics. 

Master them then move on to the next hurdle.  And there will always be a next hurdle!

Message Edited by VADave on 07-30-2009 07:13 AM

[j_osh_o]

I have been using LabVIEW about a year, and I do not consider simple state machines to be challenging.  In fact, using state machines for what you are doing will make coding much more logical and self-documenting.

There is a producer-consumer state machine template that is included with LV 8.6. Just open NEW->OTHER to get to the list of templates.

Your command should be a cluster of two elements, a string and a variant.  The string is the command.  The variant is your parameters.  It can be anything.

Your producer loop will read a line at a time from your file.  You will recast this to the string-variant cluster.  You will add this to a queue.  The consumer loop will read these clusters.  The string part of the cluster will select your state in the consumer loop.  Inside your case structure you will recast the variant to your parameters.

Easy as pie!

The XML parser on the other hand is very difficult.  It is basically C++ coding: creating objects from objects and using methods.  You will need to know a text code DOM implementation in order to under to understand it (I have done it in Python and it is somewhat similar).  Therefore my recommendation to you is to use CSV, since the learning curve for XML is long.

[leo2b]

Yes I will use CSV, the advantages is that you CAN generate it with Excel, I will use a Keyword for my states and severals parameters with one states wich will perform my test (1line = keyword + parameters), yes I think I will use a cluster to put in all.

I work with Labview 8.5, but there is the structure of a producer/consumer too.

Now I try to change the value of a enum structure with my keyword, I must "convert" my chain in an enum structure to indicate the state in my state machine.

After I will think about a queue, and how I will do that, I think I will indicate at my producer when my current state is finish and it will read the next state, but I have not work on it now.

[j_osh_o]

Here is a simple example of state machine using script.

[j_osh_o]

Version of scripting sm without queue: