Can You Contribute your views on LabVIEW Design Patterns

[Tushar_Jambhekar]

In LabVIEW there are several design patterns for developing code. and through my experience i have altered them to suit my needs. i have some other features which i would like to add in it, but before that i would like to understand the ideas of all of you, so that the template becomes more and more useful (obviously without any sacrifies on performance side.)
I hope this thread will create brainstroming, if all developers put in their ideas here.

I expect the response on following points

1. Making Template simple to use.
2. New Features that can be built inside this template.
3. is there any way to improve the performance
etc etc.

I am attaching the template i use currently

thanks

Message Edited by Tushar Jambhekar on 10-08-2005 07:00 AM

[aartjan]

In all honesty, I think that better and cleaner frameworks have appeared since the queued message handler. One compelling technique is the implementation of the event structure. Your template uses the polling on idle instead and may cause flow issues when using the event structure (not parallel).
You also use several subvi's, making the template more complicated and requiring a lot of saving of these when the template instance is first saved. All the subvi's must be template vi's as well!
Other frameworks also have implemented data passing with the message passing; a powerful feature this framework lacks.
It uses strings for message passing. I prefer using a datatyped enum.
The error handling case composes a message, but does not offer any structure that helps processing the error, which would be useful to have in the template. BTW: you keep feeding the error back to the error handler vi.

I have a template I use for pop-ups and vi's that mostly deal with front panel input. See attachment.

[Tushar_Jambhekar]

Hi Aart-Jan

1. In all honesty, I think that better and cleaner frameworks have appeared since the queued message handler. One compelling technique is the implementation of the event structure. Your template uses the polling on idle instead and may cause flow issues when using the event structure (not parallel).

I completely agree with your comment, previously I was very much fascinated by the event structure, and really it is a better option as far as performance is concerned.  But then I shifted back to queued message handler again due to following reasons

Event driven structure is incredibly powerful; but only when you want to handle Front panel event. (And when I write code for big application I generally split the code; to be executed after user event; into small pieces and then feed those messages (Hence it is similar to that one event fires lot of PSEUDO EVENTS). This splitting helps me a lot to keep my code fit on screen [I think using scrollbars on block diagrams is a crimeJ] and not just that my error handler narrow down the suspected VIs to 2 or 3(after getting used to this template no error has bugged me more than 10mins))

I am trying to create a blend of both these architectures which will give performance as well as simplicity

One more advantage of event structure is by using dynamic event registration one can handle the events occurred on other panels. But somehow I feel dynamic registration makes code hard to read.

One more thing I would like to put here and that’s related to polling. If you look at the timeout of event structure you will find that in IDLE state event structure also show behavior which is similar to polling (unless you are waiting forever) and in queued message handle polling occurs only in IDLE state. So I don’t think polling is a big issue to be considered (Except in some particular cases where system shifts rapidly between IDLE and Working states).

2. You also use several subvi's, making the template more complicated and requiring a lot of saving of these when the template instance is first saved. All the subvi's must be template vi's as well!

Totally agreed, can you suggest some ways to do this, I think two of my support VIs are absolutely unnecessary. But what about error detector.

[Tushar_Jambhekar]

1. Other frameworks also have implemented data passing with the message passing; a powerful feature this framework lacks.
   It uses strings for message passing. I prefer using a datatyped enum.

I think I never gave that a deep thought to it. That’s why lot many times my code was full of shift registers. I will think on that line. Thanks a lot for this valuable point.

I would like to get more suggestions in this direction (Priority 1 for improvement.)

2. It uses strings for message passing. I prefer using a datatyped enum.

Enum can reduce the memory usage, but I found that if we use enum in the framework code development time increases dramatically; since, to ad a single case in code developer has to manipulate lot many things. I am trying to develop one utility which will convert this string messages into the enum messages so user will develop application using string messages and application will use enum messages

3. The error handling case composes a message, but does not offer any structure that helps processing the error, which would be useful to have in the template. BTW: you keep feeding the error back to the error handler vi.

I think processing of error is very much dependant on the type of application you are writing and its very difficult to create a generic framework for processing errors.

Secondly at different time the error handling requirements are different (e.g. in development mode we might want the msg box, in tesing phase msg box as well as file writing might become essential and when application is deployed we might need to write error log files and/or email etc.)

For this I am trying to do some changes in my template which will handle the errors differently depending on current state of the code.

[aartjan]

I simply love typedef enums: the fact you only update once, the fact they prevent bugs, the fact they make great case selectors. Simply luv'm

[aartjan]

I know what you mean. The template I attached before is not designed for large software with lots of (continuous) procedures. The issue is: the event structure is too cool to leave out, unless you have no user interface. Otherwise your framework requires a parallel loop for events.. and then all of a sudden it's starts looking a lot like some of the other design patterns such as producer/consumer and master/slave. To go short: using the queued message handler is only nice for "smaller" programs/routines, and then still lacking events. And therefore it's probably most useful as a routine without interface, meant for running in the background.
This is not necesarily a good thing: I think every framework has its specific strengths.

[Tushar_Jambhekar]

hmm

yes but stricttypedef doesnt add any benefit here, because in every subVIs the cases (or states wil be different) and it will add one more step during programming

1. right click on stricttypedef and select "open Typedef"

2. again right click on control and say edit item

3. then add the thing

use of string is much faster... just place a string control and type in state name, copy the state name, create case and paste the name of state.

[Khalid]

I prefer Typedefs... one of the reasons being you can change it (add a new state, for instance) and apply the changes to everywhere its being used by the click of a button.  With a string you will have to go to each instance and change it there. 

-Khalid