LV OOP Experimental Control Code

[ibbuntu]

Hello,

I am currently writing some control code to run an upcoming experiment. Our previous control code was built up over many years and has become so unweildly that there's no-one left who understands how it works. So the idea is for me to completely rewrite the code from scratch, but in a way that can be easily modified in the future. I recently installed LV 8.2.1 and saw that it had OOP built in, so I decided this would be the best way forward.

I've started messing about dummying up the code. The functionality of the code is very simple, it simply takes in an input signal, which denotes that our laser is going to fire, and then grabs all the data from diagnostics such as cameras and oscilloscopes. It then needs to store the information sensibly, and also allow a user to view data from certain diagnostics.

So, I have several objects: a controller, a generic diagnostic (from which all other diagnostics like camera and oscilloscope inherit), a viewer, a storage controller and possibly a network control object as each diagnostic will be connected to its own computer.

That's the background. My question at the moment refers to the viewer object. As this code is supposed to be general for any experiment of this kind, it is not known beforehand what diagnostics are going to be used, and different diagnostics will produce different types of data. The viewer is supposed to be able to take data from any diagnostic, which is currently in the form of a variant data type with an attribute denoting its type (other suggestions welcome), and display it appropriately on the front panel.

Finally my question: What's the best way to acheive this? Is there some way of say having a dynamic tab system on the front panel, with a tab for each diagnostic, which when you click on the tab you get an X-Y Graph or a Intensity Graph depending on what diagnostic you are looking at?

Sorry for the long post, I thought it might be beneficial to put a full description of what I'm trying to do. If anyone has any suggestions for better ways for me to go about this I would be very glad to hear them.

[ibbuntu]

My current solution is to have a graph in a tab on the front panel for all diagnostics and turn the visibility of each page on and off at runtime, depending on which diagnostics are being used. So far I have done this without going through a "viewer" object. Perhaps I don't need one. I'm a bit of a novice when it comes to object oriented design, so any comments are welcome.

[PaulL]

My thoughts.

Part 1:

Making tabs visible and invisible as you have done certainly works, and works well. You can also change the active tab programmatically.

Another method is to use subpanels (or multiple panels) for your UI. There are lots of options depending on exactly what you want your UI to look like.

Alternatively one can change the visibility of individual controls and indicators dynamically (may not need tabs).

Part 2:

It sounds to me like you want your UI to change appearance depend on certain events. You can use a state machine with an event structure (I suspect this is what you are doing) or take advantage of the OOP state pattern (305ff in Design Patterns by the Gang of Four--Gamma, Helm, Johnson, Vlissides, or see the chapter with the gumball machine in Head First Design Patterns). For the latter you could, as one method, include control references inside the UI object you pass to the states. (Caveat: Control references aren't the highest performing way to update your UI, so if you want to write lots and lots of data this way you may wish to consider another update method. If you are just changing the visibility of controls, though, control references offer a convenient API.) If you only want to update the tab control you may find you just want to stick with a simple state machine in the UI's block diagram and this may in fact be the best solution.

[ibbuntu]

Thanks for your feedback, I will have a look at the links you gave and see where it takes me.

[Aristos Queue]

QUOTE(Paul_at_Lowell @ Oct 17 2007, 03:39 PM)

take advantage of the OOP state pattern (305ff in Design Patterns by the Gang of Four--Gamma, Helm, Johnson, Vlissides, or see the chapter with the gumball machine in Head First Design Patterns).

a) You might find the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">ongoing work to translate common design patterns into LabVIEW-speak useful.

b) If you don't find anything useful there, but you are able to successfully translate the Gang Of Four work for a new pattern, please let me know so I can update the aforementioned document.