Leaderboard

Just a tip, start off with a base class called: Instrument Then children for the different abstract types, and children to those for the specific ones. Add a FactoryCreateAllInstruments method in the Instrument Base class

The design of distributing code components among numerous self-contained processes is already geared towards the goal of modularity and scalability. Depending on how responsibilities are separated, these different processes could scale out (I need to handle 8 new devices so I launch 8 new loops) or provide modularity (one of my devices changed over from a Tek to an agilent so I just need to swap out this one process). These benefits are similar to those of the more common synchronous OO code and both styles are related to https://en.wikipedia.org/wiki/Message_passing (see especially "synchronous vs asynchronous message passing"). What you're saying is that you want to layer the synchronous style of OO on top of what is (or is close enough to) the asynchronous style of OO. This is why I ask...what specific things do you want to do with LVOOP that you can't currently do with your existing design. The answer to that should give you an idea of how much LVOOP you might want to use to accomplish those goals. To try to give an example rather than talking vaguely, actor framework has a few different goals and layers. (I am not the expert on it so I'd refer you to this document for a more official view.) -It provides an interface for dynamically launching processes. In order for this to be generic, the developers went with an OO solution. -It provides a mechanism for handling messages generically where each message is bound to a particular hierarchy of processes (eg mymessage might perform actions on myclass, myinstrmessage might perform actions on myinstrprocess, etc). Actor framework combines the two but it sounds like you only want the second bullet -- unfortunately, this is where most of the class implementations are. I mentioned half-way routes...one *example* is that you could implement something like this: have a class called "myStateInfo" and it has a "handleMessage" dynamic dispatch method which takes a string and a variant. In the "handleMessage" method, you have a case structure based on the string, and you use that string to perform whatever actions you'd like. In the "default" case, you call the parent method. This would give you some measure of reuse (you don't have to implement a message handler that your parent already implemented) but would only require 1 class per process.

Hi, Didn't know the Zybo. Looks great. Well the fact is, NI is providing on ni.com a kind of NILinuxRT x86_64 recovery image for PXI with lvrt 2015 installed inside. I'm working on it for home-learning needs since a couple of weeks. Just a hobby. I was curious on the technical faisability and basically only checked the data transfer mechanisms. Maybe there is some more important part of code to try. Or more killer bugs. But here's what I managed to run with the NILinuxRT-VM theme in mind : - About Linx 2014 on a raspberry : an upgrade to 2015 means to a "RTPlatforms.cpp" error by the lvrt binary. Guess it's not quite the same. Maybe a special compilation for this target ? - Chroot the recovery on a standard and virtualized Linux Mint with the LINX method. Works well. We've got quite the same functionnalities as LINX, but not the RT code : standard code (no RT), run-in-source, build-and-deploy. But not the timed-loop (don't know why, even with fake-hwclock. Got an err -825 CPU issue). - Run the recovery on a VM in Virtual Box. Quite simple to do with some lucky tricks. It's better : timed-loop, RT Fifos, source-build and deploy are fine. We can add the network streams and the shared variable client easily (not the server). It was running well during a single day. - Installed it on a real x86 singleboard, a lattepanda. Maybe an Edison could fit. It's running. Noticed the Arduino device inside is recognized by the kernel (didn't check for the other peripheral devices). Just starting with it. Really fun. All of them runs the real-time engine. The last 3 items are not 2015 locked. It is upgradable for 2015 SP1, 2016 and so on. (-License point) For all of them, MAX is not an issue. It begins as it seems that LabVIEW needs to declare the shared variables in MAX to operate the networked variable engine server on the target. So the target-VM must (at least) be detected in MAX to obtain an equivalent of a full autonomous device. Much harder. I'm still discovering about this (MAX see hardly my VM). fmorandat

Been there, done that. I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck). I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great. The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP. Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunnels). Performance is ok, but as I de-LVOOP it is finding another gear. I create worker pools consisting of simple LV workers and similar C++, Java, or Python workers and see what share each worker does. LV is behind, but getting up there with the big boys. The LV9 to LV12 performance kick was also welcome here. The AMQP implementation gave rise to one of my new mantras: No LVOOP in a loop.