dmurray

I've been looking at implementing a CRio-style architecture for a Raspberry Pi 3, and I'd appreciate some feedback on what I currently have, and how I can improve it. My main aim is to get a solid architecture using mid-level techniques (say, CLD level) because most RPi users won't have much LabVIEW experience. Even CLD-level may be too much for a lot of people, but I think CLD level techniques are a minimum requirement for a decent architecture. 

I'm using the NI LabVIEW for CompactRIO Developer's Guide as a reference, although I don't have any embedded experience. Also, I use the Makerhib LINX library to interface with the RPi (available on VIPM). LINX running on the RPi is an embedded Linux application, although it's not real-time. Also, it's basically a headless application (you can't view FP's on a monitor connected to the RPi), although you can develop and run VIs in interactive mode i.e. view your front-panels on the development PC. The headless mode is ultimately how I want to use it anyway, with a TCP server on the RPi, and a TCP client on a PC/Laptop/etc. Another thing is that RPi running LINX only works on LabVIEW 2014. I'm using the Home edition as it gives access to the Control and Simulation package, plus MathScript (neither used in this architecture).

The system in this example is very simple as shown below. The current architecture I have is also shown. The RPi simply reads the temperature and Alert signal of a PmodTMP3 sensor in a Main Processing Loop, updates the UI via another loop using CVT data, and turns an LED on if the temperature is above a set limit. 

Some points on the server/RPi side:

1. The 'Main Processing Loop' is a sequencer which reads and writes the signals as mentioned above, but it also has a queue so commands can be sent to the RPi. Commands in the example are 'Set Temp Limit' and 'Set Temp Hysteresis'. These commands are sent by the client and processed by the TCP Receiver, where events are triggered for the Event Handler to add the commands to the Main Loop queue.
2.  I use CVT to pass relevant values between loops i.e. 'Main Processing Loop' -> 'TCP Send', and 'Main Processing Loop' -> 'UI Update'.
3.  I use STM for TCP functionality, as I find the Connection Manager makes life a lot easier.
4. The TCP Sender sends data to any connected clients, the data being the temperature and alert values.
5. Because of the embedded nature, standard button press functionality in events is not available on the RPi side, so to shut down the code in interactive mode, I use a Stop button and event in the Main Processing Loop.
6. I use a global Stop value to stop loops when I want to close the program. This seems to be used a lot in CRIO applications. Any better solutions?
7.  I'd like to have the Main Processing Loop as a sub-vi so that I can tidy up the block diagram, but I can't work out how to do this (because of the Stop button used in the loop). As mentioned, standard events can't be used, and neither can references to FP controls (unless I'm missing something). Any suggestions on how to solve this? Same question for the UI Update loop. (Note it wouldn't be a problem in a headless application as I would have it free-running, and use commands from the client to shut-down the program). 

There's not much going on on the Client side:

1.  I have a TCP Receiver which updates the temperature and alert signal values on the client UI.
2.  I have an event handler which sends Temperature Limit and Hysteresis commands back to the client.

So my general questions are, does anything really suck, any suggestions for improvement, etc. I also have questions on sharing the RPi connection resource so that I can have more than one processing loop (e.g. one for collecting data from the RPi, another for writing commands to the RPi), but I'll leave that for another thread.

I've attached the code, but there may be an issue with dependencies. As mentioned, the code uses STM, CVT and LINX add-ons. Anything else missing should not be a problem in looking at the architecture.
 

RPi Temperature System 1.zip

PmodTMP3.lvlib

Thank for the further insights, in particular JKSH for your post. I think your link to stackoverflow.com summarizes it for me as regards my OP:

An abstract function can have no functionality. You're basically saying, any child class MUST give their own version of this method, however it's too general to even try to implement in the parent class.

A virtual function, is basically saying look, here's the functionality that may or may not be good enough for the child class. So if it is good enough, use this method, if not, then override me, and provide your own functionality.

I'm a little bit wary about the comments regarding children inhibiting parent behavior, as I thought that definitely was bad practice. But I haven't come across any situation where I need to do that so I won't worry about that for now anyway. Thanks also for the insights in throwing exceptions when a method won't be over-ridden. That's something I was thinking about, so you've saved me a question. Cheers, all.

Thanks for the replies, guys. (Thanks also for the links, ak_nz). That (mostly) clarifies things for me. ak_nz, I won't have a problem with children restricting the parent functionality if I do override the method at some point - I guess you're talking about LSP, right?

One final question on this: once I put code in my abstract parent method, is it technically no longer called "abstract"? I can see that it doesn't matter functionally, but I just want to get my terminology right at this early stage. 

I have a fundamental question on HALs and abstract methods that I'd like clarified, please. In my HAL's up to this point I've been using a parent with abstract methods, implementing concrete methods in the concrete product(s) (see here for example), and using dynamic dispatch as appropriate to execute the concrete method. I think this is a standard technique and it works fine for me.

Now I have another layer of abstraction I want to implement, but in this case the concrete products share a lot of functionality and often I can get away with just executing the same method for each product. Should I just go ahead and implement this logic in the parent method? If I do, that means I no longer have abstract methods in my parent (right?), so am I breaking some 'good-practice' rules in OOP design? 

Or am I just getting bogged down in semantics? 

[by the way, I have loads of little niggling questions like these which I may ask as I'm going along in my OOP learning - hope you don't mind.] 

Thanks for the reply. I probably haven't explained what I'm doing very well and turned it into a difficult problem, when probably all I'm trying to do is implement some simple messaging. Even the Template pattern is too elaborate, to be honest. I've been playing around some more, and currently what I'm looking at is using the "Start Asynchronous Call" VI to run in the background and scan for connected I2C Adapters. If the status changes e.g. if the number of connected adapters goes from two to one, or one to zero, this VI sends a message to the higher level, and the higher level makes a decision on what to do. For example it just checks to ensure that the adapter it is using has not been disconnected. I'm using User Events to achieve this.

To be honest I don't really need this functionality in the HAL, as it just adds unnecessary complexity. But I'm struggling a bit with collaboration between objects in LVOOP and this seemed like a good opportunity to work through some of the concepts. I know there are a lot of good messaging threads on this forum but the discussion is often very deep and it's hard to pick out the fundamental techniques. So my new plan is to look through some of the implementations in the code repository to try and extract some of these fundamentals.

Thanks again for the reply.     

Hi all.. I've been playing around with various HAL implementations for a while now, and I have a question on implementing some simple "state" functionality in the HAL. I've attached one such example - It's just an abstraction layer for a range of I2C Adapter modules that I use (or intend to use in the future). So my parent class is an abstract I2cAdapter, with overridable (dynamic dispatch) methods and exposed private data, effectively forming my interface to upper layers. Then at run-time I will just instantiate one concrete 'product'. (By the way, when I say "Adapter", it's nothing to do with the GOF pattern). 

I need to think a bit more about reference use so. For now I think I'll use what's easiest, and think about the consequences later!

Re. HALs: The blog post is very helpful. I'll think a bit more on this later, but for now I think a basic hierarchy is as shown below. For example, some devices will have both PMBus and SVID comms, some will be PMBus only, some will be pin-configurable and may need no other comms at all, etc. I also need to think about being able to add future devices and interfaces as simply as possible. In fact the serial-SVID comms approach I use is just prototyping work; I soon hope to add a better USB-type interface.

Or maybe the hierarchy needs to be switched around: device families on the second layer, and interfaces at the third layer? Anyway, there's plenty for me to think about. I'll probably start a separate post when I have something more concrete. For now I really want to get back to looking at the ideas from last night.

This has been very helpful for me, thanks again.

Hi Matt,

Thanks for the reply, there are some good points:

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.

This is a valid point - I accept that my fundamental code doesn't have a good 'OO' feel to it yet. My only exposure to OOP was in my university days a good few years back, and I can't really say I 'got' it then either. Although at the moment I am reading a couple of books on both OOP and design patterns; it's just that time is the enemy!

In this case, there's definitely some commonality between the two interfaces, but they're also quite distinct (if that makes sense). PMBus has a much larger command set and handles most of the comms. SVID is a proprietary Intel interface with a much smaller register footprint in the device. And where they do share functionality, they tend to use different formats (for example a common task would be to read back the regulated load current, but there are subtle differences in how it's done in each I/F). But I'm sure there's a way to break down (combine?) the interfaces into a proper OOP structure; I just don't know enough yet to do it.

I'm also thinking that maybe I need to have some sort of a HAL here (so that I can use the code with different devices?), but again I'm not sure how to go about it. I know there's a good white paper on HAL over on NI that I keep meaning to have a look through. It's just another thing on my learning list.

 

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.

Again, I just wasn't sure about the right way to go about things, but I understand a bit more now. I'll definitely start using controls as part of the class data now - obviously it makes a lot more sense (especially when it's pointed out to me!). I wasn't happy with all the FP references anyway, and they would have been a bit of a nightmare in the full app I have planned.

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

I really like the Actor Framework but it's definitely beyond me at the moment. My plan over the next few months is to nail the fundamentals as much as possible, particularly some of the fundamental OOP concepts you mention. But I am thinking of using sub-panels in some way in my app; for example there are a lot of waveforms I could show, and I think it might be a good way to learn about sub-panels (I haven't used them before). I haven't even used User Events yet either, so I'm trying to think of a way to work those in without over-complicating things.

But thanks for your reply, it is definitely helpful.

Derek.

Hi Elijah,

Thanks for taking the time to reply. As it happens, just this evening I dug a lot deeper into your code (the Plugin Handler Command class in particular) and saw how you were passing data between loops and other classes, and I had quite a few 'A-ha' moments. Your replies clarified a lot for me too, so I don't have much of a follow-up:

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.  

Yes, that was the plan, but I wasn't sure how to go about it, but as mentioned I think understand a lot more now. In fact, even if I wasn't going to share data I'd consider using the methodology as it's such a neat way to code. I'm definitely a fan.

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)

Okay, this sounds much better, I'll definitely implement this in some form.

 

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

Okay, thanks for clarifying. I'm thinking now that I've never really used sharing between loops very well in my usual QSM designs. In one design, for example, I used a crude semaphore method to control access to a global log variable.

 

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).

Okay, makes sense. Like I said, even just the neatness of code makes me want to switch to OOP anyway. Thanks again for your help, it's much appreciated.

Derek.

1. Read back basic info from the device (part name, FW version, etc). 
2. Carry out basic control of the regulator, such as setting the output voltage, over-voltage limit and switching it on.
3. Read and write some internal registers.
4. Continuously monitor a small sub-set of registers, and update a Vo plot.
   

Very Basic UI.zip