06-05-2006 11:55 AM
Hi,
Here is my VI's that I captured the previous jpg from.
Be warned this started l life from TestStand 2.0.1f1 and LabVIEW 6.1 and although I have loaded into LabVIEW 8, I did have to make a few deletions from one of the Tree Control Nodes.
It not very pretty, as I was only playing around with a few ideas at the time, so its got controls and indicators scattered all over the front panel.
Also the VI was invoked from a Step in a SequenceFile and not in the Operator Interface. I did notice that when I ran it in TestStand 3.x, some of my steps in the main were not set to Skip as expected.
I haven't bothed investigating why.
It may provide you with some help.
Regards
Ray Farmer
06-05-2006 01:36 PM
How much code you have to write will depend on how many changes you make. If all you do is replace the sequence view control on the Sequence File Tab, then you will have to write your own mouse handler for the left clicks. You can also not worry of the left clicks and use the options from Execute and Debug menus. You would still have to write some code to set the correct sequence execution based on what is highlighted in the tree control. You could leave sequence view control on the Execution tab and the Report View control on the Report tab to avoid re-writing any of that.
The ActiveX controls save an awful lot of coding but you are limited in how much customization you can do. At the other end of the spectrum is the old TestStand 2 Operator Interface. The code for this also ships with TestStand 3.x and you can look to see how much coding was required to implement everything with native LabVIEW controls.
06-16-2006 01:41 PM
06-16-2006 02:43 PM
06-16-2006 03:05 PM
06-16-2006 05:25 PM
06-17-2006 12:02 PM - edited 06-17-2006 12:02 PM
To mrbean -
There are many reasons that TestStand does not offer an expandable tree view for editing or running of sequences. Although many of the issues that I list do have solutions, but they also have side effects. So some issues that were of concern include:
1) Once you start displaying multiple levels, which may include multiple files, the display no longer displays the notion of sequence files. In general, we wanted the editor to be file based.
2) Recursion is allowed so we would have to display a sequence multiple times in the tree view.
3) For dynamically called sequences, it is difficult to display the contents of the sequence that is called. The user would either have to open a new top-level or specify one of the possible sequences that could be called for the node in the tree.
4) When running, an execution could be many levels deep and the tree view could be potential large and fairly unusable. When you switch between threads, the treeview could drastically change. Also when going into and out of a sequence call, the display might have to auto expand or collapse and some users might not like the default behaviors that we define.There are many more...
In the end, we felt that displaying sequences similiarly to a code based ADE was the appropriate solution for most users.
Now you seem to want to be able to open a parent sequence, expand a child sequence, and potentially run a subset of the steps in the child sequence. You need to consider how you plan to implement only executing a subset of the steps in a child sequence. TestStand executes all steps sequencially in a sequence and various looping options can change the order of execution of those steps. The simplest way to alter the execution of the steps in a sequence before they actually run is to force TestStand to skip steps, but doing this edits the sequence file. Also, if you skip a flow control step without skipping its corresponding step, TestStand execution can error. Is this how you intend to implement this?
Will you also be attempting to display the execution in a tree view?
Message Edited by Scott Richardson on 06-17-2006 12:02 PM
06-17-2006 12:27 PM
06-19-2006 08:20 AM
06-19-2006 08:35 AM