Leaderboard

Matt raised several excellent points. In particular, he brings up a valid point about the UI loop and the use of references - sometimes the simplest approach is the best one, and it's probably more than adequate in your scenario to simply wire the data to the appropriate terminals as it arrives. I go back and forth on the use of references - it's certainly nice to be able to send commands from anywhere in the system to a single process than then knows how to display them, but allowing data to simply flow to the terminal is often more readable, easier to debug and definitely more performant. I tend to use references when I know I'm going to be using a lot of VI server commands to act upon the UI anyway, especially since it's best to decouple this from other processes. That being said, not using references will not mitigate the potential nightmare of a very large front panel. Depending upon how large you intend this panel to become, you should consider relegating logical groups of UI components to subVIs and displaying them in sub panels. Put generally, when you start thinking about having tabs, start thinking about a sub-panel too. Matt also brings up a good point about the use of classes to represent the different busses in your system. The command pattern is a simple way to bridge knowledge of traditional LabVIEW patterns like PC-QMH to classes, but the real power of OOP for LabVIEW users is when you have to represent multiple similar-but-different components of a system, such as hardware, measurements or in your case: busses. The real trick is determining where in the architecture of your system to abstract functionality such that these devices can be used through a common interface that can automatically take advantage of device-specific functionality under-the-hood. In your case, the generic command set would be defined by a base class and children would extend this by implementing the unique functionality for the bus they represent. I recently put together an example of using the Actor Framework to build a measurement and hardware abstraction layer system. It's a deep dive into Actor Framework, but this blog I wrote on the design decisions I made may still benefit you as you explore HALs. You might check it out if you have time and see if it yields any insights on how/where you would abstract components of your system.

PS: No such thing as too basic of a question!

dmurray, One thing that I see here is that there is room for more generalization. Basically, you have one device which may communicate via two different interfaces: serial and usb if I understand correctly. I would suspect that the voltage regulator may take several of the same inputs and provide the same outputs (possibly) regardless of the communication method; you will still have to turn things on and off, send voltages, etc its just which low level VIs will be called to accomplish what you want to do. And I guess this is where the art of OOP comes in - it is not entirely clear to me how to delegate this. Do you have have commands that are specific to the interface and you simply pass the reference to the interface as well as any data to the command object, or is there a better way of doing this? Or might this be a terrible way of doing this? I don't know. Also, I can't remember exactly what Elijah's original demonstration looked like, but I recall that he also included references to controls on the front panel. While that might have been a good way to implement that there, it doesn't seem entirely clear why you would do this here. Why not simply have the data relevant to the command passed in with the command itself (i.e. why is that data not part of the class)? This might simplify your structure a little bit - instead of having two separate classes for turning on and off the regulator, you might simply have a single command instance that has a bool as the primary member and the regulator is turned on or off based on this bool. This would also make unnecessary the property node calls on the front panel controls. And concerning Elijah's comment: I did something similar to this with a much more complex system and came up with my own architecture in which I had a UI Facade which contained a single subpanel. The facade then controlled the user view through controls that allowed the user to change that view by dropping in new front panels that were all started in the background when the facade was started. Each of these front panels had very specific functionality related to discrete pieces of the system. That being said, there was some overlap in the data retrieved by the facade and the data that was needed for the different front panels. So each front panel could subscribe to some or all of the data that was received by the facade (observer pattern). I think in the end, with all the queues and events required for communication, that I ended up with a poor man's Actor Framework. So, my feeling is, that for something simple, this is an excellent idea. But, as it gets more complicated, you might consider implementing Elijah's idea with a framework that is already available rather than rolling your own. But that is probably a step farther than you want to go. I am not sure if I said anything useful (following on someone who knows a lot more about this stuff might not be productive), but I hope it gets you thinking. And it was nice first go. Cheers, Matt

Hey dmurray, Glad to hear you found the command pattern example useful. It was my first successful application using OO, so I created the manual in the hopes of leading others down a similar path. I took a minute to glance through your code, and one big question jumps out at me: are you actually passing data between these loops? One of the major reasons to use the command pattern is the encapsulate the data associated with a command inside of a class instead of passing it as a variant. Given that none of your classes appear to have private data, I can only assume that you aren't actually sending information between the loops. If my assessment is correct, the use of this pattern may be overkill - though there's nothing necessarily wrong with using it. However, your second question leads me to believe that you may actually want to pass information between your loops. Your UI loop already contains references to front panel items you might want to update upon receive data - ideally, it only updates the necessary component upon receiving new data. Rather than be free-running, it could respond to commands sent from other loops that contain the new value to be displayed. As an example, you would have a class to update a graph and the private data could be wafeform data and cursor information - any other loop who had access to the UI queue could then send a command to update the value of this graph. PS: Rather than increasing the scope of this loop as you add more UI elements, consider having sub-diagrams that load separate UIs with their own dedicated processes) Q3: One loop two sources is fine - in fact, it's what queues are best at. Even if you weren't using the command pattern, it's common to have multiple producers of commands/data pumping that information into a queue, which should only ever be dequeued in one location (ie: the consumer). The approach you've described for logging sounds appropriate Q4: A dialog should be treated like a free running process that has it's own P/C loops on the block diagram. For a good example of this, see the sample projects and how they invoke an options dialog. Finally, is this the right pattern? It's fundamentally a producer/consumer queued message handler (P/C-QMH), but we use OO instead of enums with case structures. As such, it's just as appropriate a as a regular QMH would be, but you're able to encapsulate the data you pass between the loops using classes (should you choose to do this).