Random Ramblings on LabVIEW Design

Cartoon time (based on a true-ish story)

Words to look out for in requirements specs....................

Universal,  flexible, futureproof, so simple that no skill is required to operate, delivered yesterday, bug-free

Adverbs like completely or absolutely.

Robust software costs $$$$, Completely robust software costs $$$$$$$$$$$

The double whammy ... flexible and easy to use. Design is a compromise between flexibility and simplicity, don't put them together, they will fight!

The universal test framework was brought to you from a bar in Paris by.....Marcus Johnson, Pierre-Yves Le Bas, Martin Peeker and me.

The blog hasn't been nearly random enough, so this is my bid to get back random points.

Something less surreal next time.

Much Love

Steve

As with all these blogs, please add words to look out for in the comments, I'll steal them and claim them for myself (if they are good!)

The discussion on functional encapsulation and all the comments got me thinking....

I've been working this way for any years and have got used to the limitations of the action engine, but what if I had it all my own way.

The stated limitations are...

• Managing Un-used connections
• lack of inherent scaleability
• people prefer lots of coloured wires
• people prefer functional decomposition (i.e. lots of non-cohesive functions acting on data)

Now the latter 2 we view as a design weakness and they view as a strength and therefore it comes down to who's biggest. Actually in the end if you are writing great software in whatever method it doesn't really matter. So if you don't mind I'll concentrate on the first 2.

So in my blue sky world LVOOP would go like this.

From some point on the Functions Palette, quick drop, Tools Menu or Project instantiate a new object.

This will give a list of the classes in the project and allow 1 to be selected.

When selected the object will drop on the block diagram and it will get a new instance name, this instance name can be changed to better suit the problem.

The first 2 blocks on the menu would be standard for all classes. Go to Class Diagram--> will bring up the UML diagram for the class, similar to the Symbio tool. Changes can be made to the classes and then we return to the block diagram. Create new instance -->does what it says - this will give us some simple scaleability. -------------------------------------------------------- Get Ref -->this will allow standard LVOOP to work Class ID, Class Name and Get Instance Name-->basic housekeeping -------------------------------------------------------- Initialise-->Close these are the main PSU classes methods -------------------------------------------------------- Set Over-current and Set Over-voltage-->sub-class methods for new capabilities

The data encapsulation of the class will be globally assessable inside the scope of the object instance.

The method selection will set the inputs and outputs as in a polymorphic VI.

So finally we'll get back to our familiar diagram.

Is this too ambitious to put on the ideas exchange??

I think that's just about enough action engine stuff for the next year or so. My next blog will be a cartoon.

Hugs and Kisses

Steve