drjdpowell

That code should work fine without the DVR. It shouldn’t hang the application. — James BTW> look into “Variant Attributes” as a higher-performance way of doing look-ups like that.

One can have a “Hardware” actor, that is the only process to actually communicate with the actual hardware. That actor pulls from the hardware, but pushes status changes to other actors. [AQ may be thinking of this “Hardware” actor rather than the actual hardware.]

Random comments: 1) An “action engine” is a by-ref construct very similar in use to a DVR, so I don’t understand how you could have experience application hang with an action engine. Having an action engine with a DVR inside it seems redundant and overly complicated. 2) I actually have some mixed by-val/by-ref objects, but they are “naturally” that way, because they are a by-value object that “decorates” or extends a reference. For example, a “configurable forwarding address” which wraps a communication reference (queue, etc.) with by-val instructions on how to modify messages sent to this reference. I also have some mixed objects that I would probably have been better off making entirely by-ref.

One other useful technique is to create an “abort” notifier in your “Controller” process, pass this as part of a “Do<whatever>” message, and have the execution loop check this notifier at appropriate points. It can even use “Wait on Notification” in place of any “Wait” nodes it might require. Package the “wait on notification” inside a subVI that outputs a “process aborted” error cluster, and you can stick it in any chain of subVIs sequenced by the error wire. — James PS to Daklu> I was excepting you to mention a true state machine as a “Sequencing alternative to a QSM”.

If you’re following the Actor Model then actors should not share data by-reference. This means that different Actors often must either keep a copy of the info they need, or request the info from other actors when needed (the first option is probably best). For your “Resistance=5” example, the UI could send a “Set Resistance Request” Message, and the Controller would check the value against its copy of the parameters. If invalid, it would sent a “Resistance=<old> value” back to the UI, followed by some message to display a warning to the User. If valid, it would send a “Set Resistance” message to the Hardware Actor. The Hardware would then send a “Resistance Update” message to the Controller, who would send a copy to the UI.

Funny, I got my CLA late last year with exactly the same set of marks, 10-16-18-26, with an architecture quite different than the example. I was annoyed by the low architecture mark, as I felt the architecture was complete and solid. — James PS. I was particularly annoyed by a comment of "Architecture not abstracted to switch over to field hardware.” I used abstract parent classes, with “Simulated” child classes injected at runtime, and a large comment explaining the intention to replace the simulated modules with hardware ones as required.

Those VIs work fine for me, and they don’t contain any references to subVIs that aren’t part of the standard LabVIEW package. You might have a problem in your LabVIEW installation. I would suggest you try reinstalling LabVIEW.

Be more specific. What “example VIs” are you talking about?

And one can have a single task waiting on multiple notifiers, which is also event like and something one can’t do with queues (though, unlike with the event structure, the notifiers all need to have the same datatype).

Look into “local variables” and “Property nodes (Value)”. Both can read or write to both controls and indicators.

LAVA was down for some kind of upgrade around the new year. I suspect the problem is associated with that.

Tried it from a totally different location on a different computer. Same thing, same symptoms. Could someone else have a go at trying to upload something to the CR? You don’t have to actually complete the submission; just try and upload a file.

No. The static VI just calls the dynamic VI, passing in the class instance and so allowing dynamic dispatch. Below is the static VI I use:

I still have the problem, and I can’t even upload images to the CR. Tried both uploaders and multiple browsers.

I am having a problem uploading a new version to the Code Repository, but you can download it from bitbucket. It is extended to work with multi-D (rectangular) arrays.

Now I can upload images to a post, but still not upload a new file to the CR: attachment=7615:ThisUploadFailed.png]

Are they “orthogonal”? Actors encapsulate their internal data, and messages to the actor can be thought of as methods of an object.

Hello, I’ve just found that I can’t upload files to the LAVA CR. I was trying to submit a new JSON LabVIEW version and I kept getting a “This Upload Failed” error message. See below: ... Well, I was about to attach a png image to this post to show the error, but I couldn’t, as I have the same error when attaching files to posts Anyone else have the same problem? — James

Why not just use ShaunR’s package?

Surely your class has some non-private member VIs in it, or it can’t be used by anything else. Presumably this is you loop/process VI? I don’t see anything wrong with it.

Yes, that’s how I (and many or most others) would do. I would have dynamically-launched VIs as “components”, which I think of as “parallel processes” or “actors”. I use LVOOP for the inter-process communication (“messages” and “addresses”), with each parallel process being represented by-reference to its LVOOP address object. The address is effectively by-reference because it wraps some communication reference like a queue, user event, or TCP client. Note that an “actor” is effectively like a by-reference, asynchronously-accessed, active object, which is not the same as standard OOP objects in text languages, which are by-reference, synchronously-accessed, non-active objects. One can create the latter using a DVR in LabVIEW, but whenever I’ve considered using one I’ve always decided that stepping up to an actor is better (one concern, though, would be speed; straight DVR access will be fast compared with a request-reply exchange of messages via queues).

bsvingen, are you using “singleton” in the same meaning as in OOP; something of which there can only very be one instance of? Because I don’t see how that is useful in something like a PID controller, which one might easily want multiple of. Do you perhaps use “singleton” to mean any by-reference thing?

As ShaunR’s SQLite package in 2009 was not satisfactory for you then I assume you need before 2009. In which case, “no”, as I use features of 2009 or more recent. You should be able to back save Shaun’s stuff, though.

Is there a link to the wiki from LAVA? Perhaps there should be a prominent one. I always forget the LabVIEW wiki exists, and had to Google it to find it.

If you can give me a 1d array, and the dimensions to calculate the offsets, it will be easy to recursively convert to nested JSON arrays inside of JSON arrays (and it will work for any number of dimensions). — James BTW> One other issue that occurs to me is “ragged” arrays, arrays of other arrays of varying size. In LabVIEW, I would make a ragged array from an array of clusters containing arrays; in JSON, it would be just an array of arrays of varying length. I would probably try and add support for conversion between these types, too, if we’re going to support multi-D arrays.