large application planning for LVOOP - Is ACTOR and/or "Plug-in Architecture using Packed Libraries" suitable?

[QFang]

Hi,

I'm trying to do some up front design for a totally new platform for our software solution, and I have some questions, the main one beeing "Is this LVOOP a good direction to go in?"

I use LabVIEW 2011 and I would consider myself fairly experienced at LabVIEW (CLD, 2.5 years of professional/commerical development in a large LabVIEW "driven" company), LabVIEW RT and LabVIEW FPGA, but not at all with LVOOP. I have now been given the time and resources to "take the step" in designing the "next generation" platform for a customer and want to make sure I get off to a good start. I have some experience with proprietary (in-house) plug-in and dynamic architectures for the Windows platform, but these don't seem to play ball with RT/cRIO.

I effectively have 3 applications/situations to consider. I think, based on my limited experience with LVOOP, that the ACTOR framework is a perfect fit for 1) and 2), but I think that for 3) below, I need something else?

1) headless cRIO - the cRIO connects to n instruments where "n" is determined by a config file that can be ftp'ed to the cRIO. (reboot curretly required to re-read ini file on file change). In this mode, each instrument should run in paralell (actors??), gathering data and saving to instrument specific log files. This is currently done by manual loop duplication on top level and limited to 2 instruments. --I have yet to manage to launch VI's dynamically on the cRIO for some reason..but that will be a separate post.   A planned update to the engine is to also have it listen for TCP (or UDP?) connections and serve out data from the instrument to a host/windows remote viewer. Currently, it also listens for, and serves Modbus requests, but again, because of me not getting dynamic VI's to work on the cRIO, I manually duplicated and hard coded for up to 4 Modbus connections.

2) running n instruments from a windows environment. It would act and function exactly as in "1" above, and probably should run as a "service" or windows daemon. I was hoping that 1 and 2 could be essentially the same code, just compiled for windows or cRIO by allowing certain sections of the code to be self-aware of what target it is running under. Again, I feel that the ACTOR framework would be perfect for this, since each instrument is both slow, and completely isolated from each other).

3)  a plugin based windows framework that can be used to view data from "1" or "2" above (by connecting to cRIO/or self/localhost), create configuration files (that can be pushed to the remote client or the local daemon), log file viewer and post-analysis module and so on and so forth as new usability requirements evolve.  Because of this "now we want to add this functionality" product evolution, I'm thinking that this fits better within the "Plug-in Architecture using Packed Project Libraries" by Michael Lacasse, allowing each function (or plug-in) to be developed and maintained separately, but running on the same core exe? Other planned future functions include a "deployment" utility to deploy and configure new cRIO's without using the project (by "restoring" zip images to the cRIO), as well as a more full-featured data mining and "playback" plug-in for working with previously collected data.

 Questions and comments on direction(s) both for planning or coding would be appreciated.

[Kareem_W.]

I will look into this and try to answer your questions.

Regards,

[AristosQueue (NI)]

Your use case #2 on the host is definitely what Actor Framework was designed to solve. For your use case #1, no one has yet (to my knowledge) attempted to deploy the Actor Framework onto a real-time system like CRio. In theory, it should work, but no one has tried it. There is possibly more memory fragmentation from the framework than is acceptable on an RT system; if you do choose to use AF for your work, please let us know how it works out. Getting it working on RT is something I would like to do, but the AF is a side project for me, not my main assigned task, so I haven't yet had time to try it.

I am not qualified to advise on RT architectures -- after 11 years working on LabVIEW, that's one area that I'm just now starting to get into. I hope that Kareem, the AE working on your request, can gather together more advice.

[JÞB]

Just to hang with the thread. 

@AQ- After struggling mightily to move the Basic Archetecture of the application previewed in the Community Nuget series: Application development- into LVOOP I find I've re-invented the wheel.   (albeit with a different standard of "roundness", I hadn't solved the coupling issue yet)  I guess that shows me for missing NI weeks! 

I am curious about dynamic dispatch on FPGA.... Something there smacks of resource starvation but I can't play with it at the time.  Any Idea about gate hits for a dynamic IO pattern?

[QFang]

Appreciate your reply Aristos. If I read between the lines, you are saying that the windows application in case #3 is NOT a good candidate for the actor framework? Is that correct? I might still go the actor way with #1 and #2, but I need to find some simple projects to build up to that level I think. Still feeling a little overwhelmed with the LVOOP way of thinking, coming from QSM's and "action engine" style functional globals.

[JÞB]

the LVOOP tutorial here is a good place to start.  It does seem daunting but the same software engineering principals apply.  Haveing reciently jumped in the LVOOP pool myself I can say - the water is fine."

[AristosQueue (NI)]

I guess I misread your #3. I was thinking you were trying to load different plugins onto the CRio, and so I was shying away from commenting on it. Can you clarify what you're wanting to do in #3?

[QFang]

I could see why it would be unclear. So, I'll try to clarify.

I want to develop a Windows only "user-interface" with various functionality available to the user depending on plug-ins installed/available and selected during run-time. (This allows us to sell "add-ons" later in an easy way, as well as having internal functionality and tools, all through one framework, which seems like a very nice scalable and maintainable way to do it).

Basically #1 and #2 will both listen for a TCP connection (or maybe I'll do a UDP broadcast, not sure yet), so my "3'rd program" (with plug-ins) will be able to query for instrument data either by connecting to "localhost"/ ip 0.0.0.0 if the user is running the windows version of the instrument interface, or if the instrument is running on a cRIO, it can connect to whatever ip the cRIO is on. So my thinking was that one plugin for my Windows UI could when run, basically retrieve data over the network. Another plug-in could load tdms files and do special analyzis and processing, 3D displays etc. 

The reason I wish to have this de-coupling between the software that runs the instrument/logging functionality and the user is that the instrument data logging should/will always be running, and sometimes the target (cRIO or Windows) does not support a local UI for the operator/technician, so it seemed like a good idea to decouple UI/viewing entierely from the collection/logging application.

Thus, if possible, I will end up with essentially two programs/code bases to maintain: one for the instrument/logging that will run in the background on either a windows or a cRIO machine, and the other which may or may not be running at any given time that provides a user interface with functionality determined by what plug-ins are available to the user.

Clear as mud I'm sure. 🙂