ShaunR

An action engine to do the averaging over N channels is about 2 minutes to produce one VI (~2k), that can be explained to a novice in 30 seconds regardless of the architecture you use. A class with a DVR is about 5 minutes, 3 or 4 Vis (about 30K) and you have to promise there will be only one (but that's probably OK for Neil) and could be explained to a novice in 30 secs IF he was OK with classes to begin with. What's your overhead and how long until a novice would know it "very well"?

Then I would suggest staying away from any of the class based messaging systems that have proliferated. You have to create a class (and all the overrides as well as inherit from their particular fetish for structure) for every damned message - which is comical. This is why I use simple strings for messaging..

Because of aggregation. The goal is to average a number of values all being acquired asynchronously. There needs to be a way to snapshot the multiple values at an instance in time. If you use messaging then by the time you messaged each subsystem and got a response the values are not at the same instance in time. If you use events, then the event structure only operates sequentially so you have a similar problem. The AE makes this trivial. Other solution require all sorts of hoops.

If you want to go all experimental...... There are "Tags" too which are global. IIRC I suppose they could be leveraged for this but I've never really looked at them Another thing that I used to do before databases was to use an INI file to abuse the OS cache. Most people don't realise that reading and writing to an ini file directly is almost as fast as accessing memory once cached so there is no need to keep a lookup table in memory. (you can do the same with memapped files to share between executables too). This also has the side effect of giiving persistence (great for resuming downloads that the user task-kills )

It's specmanship by a designer that never uses the end result. If you read the docs, it talks about clusters and the behaviour is the common denominator. It makes it a little bit useful for clusters while pretty much useless for anything else.

That just takes us back to: ....and you seem to now agree. Lets just keep it simple and talk about memory accessors.I don't think Neil wants to refactor all the code into several weeks worth of architectural redesign just to replace a very small component - rather a drop-in replacement for a standard (but possibly outdated) module type. (Pin for pin compatible,if possible).The problem is that for simplicity, efficacy and ease of debugging; there aren't many alternatives if you take DVRs off the table..

Everything's an airplane with enough thrust, right? Generalising to nebulous "actors" (which is just a hand-wave and means "insert your meaning here") and "objects" (which is another hand-wave meaning "describe something here") isn't the frame of the discussion. If that's the route, then I will generalise further to subsystems, services and processes since I don't have "actors" and "objects" - but that shouldn't matter, right? Just for reference were were at: and..... That's where we got sidetracked into the the LabVIEW implementation specifics of globals, wires and so on (where I lost you with my By Val/Ref.). Then you got me back with objects and actors, causing me to pass out through lack of oxygen

I think now I know where you are trying to get to, Indirection, of which "by reference" is an example. But the generalisation is inappropriate. AEs (and DVRs for that matter) are just memory accessors with some safeguards and maybe some logic. To conflate them with processes, subsystems and services where state rules supreme is a fallacy. DVRs and AEs are stateless accessors, nothing more. (That's not to say people don't try to stuff complex state-machines in AEs though )

Well. 21.3xxxx is the maximum over-range of a 20mA current loop, IIRC. I suspect you told max it is a current loop rather than just applying a scaling factor to your voltage.

Standard terms; not peculiar to LabVIEW.

Isn't that a contradiction in terms?

Well. You wouldn't get that with an AE if you have the usual "First Run" check or have used the feedback node instead of shift registers internally. However. With a DVR, no (the ref goes invalid when idle). With a DB. Yes. However. This is where I usually bring up the Suspend When Called

I really don't know where you are trying to get to now. This is starting to look like an "Anything is an airplane given enough thrust." kind of argument.

I think the main point Smithd was making is that the current thinking about replacing AEs is to use DVRs but with messaging architectures, global storage is handled differently requiring neither. You have, however, restricted your options by insisting that you don't want to use by-ref solutions (although I think you and a few others , maybe misunderstand what that exactly is since AEs are not by-ref)

Making copies is how LabVIEW resolves shared resource contention. Even with DVRs on a wire this is true except the resource is just a pointer to the data and so it is that which gets copied.However. Even then. With a DVR, you are forced to use an IPE to access it because it can be accessed from anywhere. This is your mutex around the data. Globals are not by ref. They also are copies (see above).The second biggest argument for why you shouldn't use them is that every instance is a copy of the data so liberally spreading them throughout your code is a quick way to resource starvation when that 250MB 2d array gets in there..

Software is like a fart. Yours is ok but everyone elses' stinks.

I don't have opinions. I have mental scars from fixing other peoples code.

A common thing with VISA is that you open the port then press the Abort on the diagram toolbar. This leaves the VISA session open so when you try to run again, the Open will fail (because it's already open but you don't have a reference anymore). If you go to the LabVIEW options (Tools>>Options>>Environment) and check the "Automatically Close VISA sessions" you shouldn't fall foul of that. (IMO this should be the default.) Automatically close VISA sessions—Automatically closes VISA sessions left open by the application when the top-level VI becomes idle. This checkbox does not contain a checkmark by default.

Or the Muddled Verbose Confuser pattern, as I call it. That must be the worst pattern ever invented. No-one can agree what should be in what bits. No-one ever puts the right bits in the right place after they have argued about it and everyone ends up with MC, MV or one of the other letter combinations (take your pick). Then every single one of the gazillion files only has one of 3 names (controller, view and model) In theory it's great. In practice it's foot shooting with a bazooka. Look at the "Event" examples that ship with LabVIEW. In your GUI you probably already have an event structure so create a "User Event" and get your GUI to register for it.

Not quite. I said they are wrappers around shared resources to introduce mutexes. The mutex is the VI boundary and makes access atomic. It is indeed about accessing things from processes running in parallel. I think you have forgotten that they are not reentrant so they have blocking behaviour around the resource. I'm not sure what you mean by " By-value objects are not sharable and have no use for mutexes. ". You can branch a class wire and what good would a global variable be if you couldn't put it on multiple diagrams?

Yes. And I can use a screwdriver as a chisel. (By-ref classes is an irrelevance.) Any class is a number of [atomic] methods acting on a protected storage container and this is what AEs attempt to do without the language support. Any other interpretation or extrapolation is just linguistic gymnastics.

Actors and AEs aren't equivalent. It's like saying a program is the same as a DLL. AEs are just wrappers around a shared resource to try and introduce mutexes. So you could have a "List" and methods "Add", "Remove", "Read" etc called by multiple VIs.. Nothing is "running", They were primordial classes - wrapping a global memory when we didn't have the language construct of classes.

Well. As I said. For me it's.polymorphic VIs because they have the menu in lieu of an enum (same thing but different) and de-clutter the compane. However. I don't think I have required global storage like that for a long time. Using a DB makes AEs (and a lot of other things) almost redundant since you just craft a query string.So for your average N sensors example it would be a one liner like SELECT avg(value) from Sensors WHERE status='active';

Action Engines are singletons and class clusters are an instance scoped variable, not global. So. If you want an exact equivalent then you have to jump through hoops like using a queue or a FGV (just like an AE-DOH!). The migration means you get new VI methods for each ENUM entry (I've talked before about code bloat) and forcing the user to drop a load of different VIs from a palette or quickdrop. You don't get a lot else apart from increased complexity and the ability to wave the "I'm using OOP" banner. Personally. I would prefer a polymorphic VI over a class because you still have the code bloat but don't burden the user..It looks like you have just swapped the enum for a drop-down menu and you get the adapt to type for the different inputs. If you want it as a class because.......reasons. Just wrap the action engine in some class methods (one for each enum). That's pretty much what you will end up doing if you don't use a queue and you can still wave the banner However. if you promise and "cross your heart and hope to die" that you will only have one instance then a normal class (with a DVR?) will suffice .

Make sure the VI is running before setting its position/size. This effect usually occurs when you use an external window sizer/positioner to the VI that you want to position (rather than on its own diagram) because the FP opens but the menus, title bar and sliders are visible (depending of FP settings) before they are hidden when running.