nileracecrew

I can't speak for RT FIFOs, but I have read that the normal queues are implemented as circular buffers. Not sure how/when re-allocation happens, but I assume that once the buffer grows in size, it doesn't shrink back down. Hence the N-element enqueue/flush trick.

Back to the original topic, I did find a significant caveat when using the method described above to change the object that a DVR refers to. Suppose I have a DVR that refers to a parent-class object. I replace the object with a child-class object, then later down the wire--works fine. Then, I try to replace it again with a parent-class object. The second replacement will fail since PRTC will (correctly) fail--a child-class object is on the middle wire, but I am trying to pass in a parent-class object. So, that is the case that LabVIEW seems to be protecting against: parent class DVR refers to a child-class object, and you try to swap in a parent-class object. I still don't understand why that's a problem. I'm guessing it's an implementation issue? I made a related cross-post on the NI forums to see if anyone there has answers.

I am starting to lean that way as well. In this particular case, it might create some headaches because of a need to coordinate and sequence multiple subactors. I am still trying to sort out the best approach. The actor model is new to me, but fortunately with this project I have the luxury of a little time to research and make a few prototypes before settling on an architecture. FYI, your Slave Loop post really helped my brain get around the whys and hows using actors, so big thanks for that.

Agreed. I didn't have a suitable class hierarchy immediately on hand to make a simple example, so I cheated. Trust me that it works the same way with a user-defined parent and child. There is some strangeness here, especially when you read the LabVIEW documentation about using classes with DVRs and IPEs, and the fact that PRTC is required. Absent that though, this is how I would expect it to work. A child object is technically is of the parent type, and you can mix parent and child objects in arrays, clusters, queues, etc--as long as they are of the parent type. If you really want to blow your mind, as I alluded to in my question #4 in my first post, you can get rid of the PRTC by wrapping the object in a cluster: There's a cryptic sentence in the "using references with classes" link above that says you can do this to swap objects without PRTC, but I'm not sure what's going on under the hood that makes this work, or even if it's supposed to work with child objects.

ps, Thanks for your reply. Based on what the LabVIEW DVR documentation says, I agree in principle with what you wrote. In practice it seems to do something else. I'm trying to figure out if this is expected behavior or not. I don't have a quick example to show a method override, but here's a stupid example that shows that the object mutates and preserves child class data. The DVR is a reference to an LVObject, but I use PRTC to stuff in a "Node List" object that has previously modified class data. Later on I get the object back, downcast it to Node List, and get the data out. In a larger application I was able to call an overriden method from an IPE using a similar technique.

Right, but PRTC does not throw an error if there is a child object on the wire. It only errors if the runtime class of the "in" object is higher in the class hierarchy than the target. I believe this is by design, otherwise you would break dynamic dispatch for children of the child. This is why I'm confused. If the parent DVR can't accept a child object, then PRTC is not going to stop that from happening. As far as I can tell, it does mutate. I can make a child object, modify its data, and stuff it as shown into a parent DVR without any error from PRTC. Later on, if I dereference the DVR, the resulting object is still the same child (even though it's on a parent wire) and will call overriden methods. The trouble with this approach is that it will break the DVR in the other parallel loops.

I am trying to understand the requirements for replacing the object that a LVOOP DVR refers to. I've looked at these pages, but I'm still not quite sure I have a full grasp: http://zone.ni.com/r...lassrefswapped/ http://www.ni.com/wh...er/9386/en#toc3 I have what is essentially a LVOOP hardware abstraction layer: a parent class with dynamic dispatch methods, and a number of child classes that override those methods to provide the specific hardware functionality. In a single-loop application, I can initialize a shift register with a parent class object, and then inject a child class object onto that wire as needed. I am now working on a multiple-loop application, and need a way to serialize access to the hardware object across the loops. It seems like a DVR is the right tool for this. Here is a watered down version of what I am thinking of doing: Here "Pack" is the parent class, and "PCPV4" is one of the child classes. In real life that case statement would be a state machine. Some questions: 1) Is it ok to replace a the object that a parent class DVR refers to with a child class object? In my limited testing, as long as PRTC is there, everything works as expected: I can later dereference that DVR and it will act as if there is a child object on the wire: it will call overriden methods, maintain child class data, and so on. But maybe I am abusing something here. 2) Why is PRTC needed? Even though the referred object gets replaced, the new wire is of the parent class type, so at runtime the object is already guaranteed to be of the parent class type or one of its child classes. PRTC doesn't seem to tell LabVIEW anything it doesn't already know. 3) Eventually I will have multiple objects (not all of the same parent class) that I need to keep track of, so my thought was to make a DVR to a cluster of parent objects. Wrapping everything in a cluster seems to get rid of the PRTC requirement. Why? 4) From what I gather from the two links at the top, there are more sinister problems related to swapping objects in a DVR, but I'm having a hard time understanding a) what those problems are, and b) how PRTC fixes them. Thanks for any replies.