Djed

Yes, that distinction generally determines when you'll see this behavior.

The exact details of when the exact clone is exactly "reserved" do vary for many reasons.  It's not necessarily deduce-able from the diagram since the compiler tries to optimize things.  The caller VI might grab a clone once and hold onto it for a while or it might grab it exactly as it needs it.  And yes, SD versus DynD also play into this.  Dynamic Dispatch I believe is always grabbed at the last minute because we have to deduce the right VI to call and it might vary between loop iterations, etc.

"Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*.  This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy".

However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone!  This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.

You are in the ballpark on those hidden prims but I have to sadden you with the news that we never finished them. You're lucky if you don't immediately crash the second you try to run a VI with those nodes on the diagram. Sorry these aren't going to be useful nodes to play around with. I'd be shocked and fall out of my chair if you found these used in ANY vi in vi.lib.

Off the record, NI put in stronger VI password protection purely as a user-feature, not as some sort of DRM. Our own diagrams that we do password protect are much less important than protecting our customers' IP. If you are having a problem accessing your own VIs due to mutation issues, please contact support.

Generally there is little difference between the matrix data type and a 2D array. However, there are a handful of mathematical operations that act differently. Just multiplying 2D arrays of numbers the way labview does is different than matrix multiply.

AQ's not trying to be mean in denying you internal information on xnodes. First, such documentation was written for internal purposes and as such contains "classified" information. Second, xnodes were not designed as a feature for customers but as an internal tool. As such, believe me!, they are buggy, under documented, flaky, dangerous and unfinished. They are nowhere near a feature we can support and we are not allowed to talk about them. This is not really a "protecting you from yourself" but rather not publishing an unfinished, buggy feature. Maybe someday we'll have the resources to finish and productize the feature. But for now, we are supposed to answer "No comment" according to the lawyers. =)

Can you file a bug report on this or post some (preferably simple) VIs that reproduce this issue and I'll file a report. I have an idea of one thing might be going wrong internally.

Have you considered just using a latched boolean? Boolean controls that are "latched" reset themselves to the default value after they are read once on the diagram.

Q1: How to create a tunnel? For ShiftRegisters (Child Class of Tunnel), there is a method Loop.Add ShiftRegister. For a simple tunnel, I didn't find one. Is it as simple as just to wire through the structures boundary?

I believe the answer is that if you wire from one diagram to the next, it will automatically create a tunnel for you, much like when wiring on an actual diagram. I am unsure about wiring to a structure boundary. Normally, when wiring, I just drop both nodes and then wire from terminal to terminal. I am pretty sure that it is impossible to just create a tunnel on a structure; unwired tunnels typically are removed by type prop.

Q2: Creating a broken wire. The create wires metjod needs a sink Term to be called, but how to create a loose end? I was thinking about creating a temporal variant control (indicator) terminal to wire it 'valid' first and then delet the variant.

I think that the wiring scripting methods were not created with "bad wiring" in mind. My guess would be that you cannot create a loose end through a wiring method, but rather like you would on an actual diagram, like you discussed.

Is there any priority logic that gets applied to tasks that are blocked on a DVR refnum at an in place element structure?

That is, consider two tasks which are both blocked while waiting for a refnum to become available. Is there any way to know which will be allowed to operate first? Does the priority of the containing VI affect this decision at all? Does the order in which the tasks blocked influence which will be signaled first? What about the phase of the moon?

Yair is correct; actually, all the responses look good.

I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

I believe the answers to your questions are Yes and No, respectively. Under the hood, I believe the property node is decomposed into an actual in-place element structure. Property Nodes for by-value class wires I believe are decomposed into standard method calls and so would generate no additional errors. I'll forward this to the developer to see if he has any comments.

The only problem I see is how is LV to know when to be able to allow the use of this automatic dereferencing? There would likely need to be a requirement of having both an input and output for the class of interest, but other things creep up to, such as methods which have both in and outs for multiple classes. This might require a new type of connector flag separate from the four currently used (Dynamic, Required, Recommended, Optional)?

Any thoughts on this?

Yes, for automatic dereferencing you need at the very least an input/output pairing of VI terminals where runtime type is preserved, like in dynamic dispatch VIs. We have talked before about having an "in/out" or "inplace" marker on the connector pane. The real problem with this feature however would be error handling. When you dereference a reference (DVR or any other type), you can run into errors (the reference could be closed or was never good, etc.). You will notice that most nodes that take in references also have an error out terminal. Dereferencing a DVR can definitely produce errors (not to mention the fact that the access is asynchronous potentially and this would be hidden from the user) but static methods have no error terminals. There would be no way for us to pass errors along either to the static method itself nor to the callee; instead of getting the actual class, they could get a default data instantiation of the class and be none the wiser. This is why the property nodes will auto dereference; they have error out terminals.

Also, LabVIEW manages memory for you, so you (typically) don't have to worry about passing everything by pointer or using pointers to allocate, etc.

On that note, LV R&D is collecting info to further improve edit-time responsiveness. We'd appreciate everyone who has the time to fill out this survey: http://bit.ly/aWBf1j

If you have large projects open and are doing editing of large VIs, you may want to turn autosave off. Autosave, which I believe is on by default, results in a compile and therefore a full error check every few minutes. If you are good about saving periodically, I would recommend considering this; it may help.

So to be clear, the question/answers are:

"With a string, how do the modes differ?" Not at all, the mode setting is ignored.

"Is there a difference in behavior of individual versus aggregate comparisons for scalar values?" No, the mode setting is ignored

Yes, I believe the variant bordernodes treat errors in the same way (for the same reason as DVRs).

No, I don't think it makes any difference on LabVIEW's side which error-out terminal you wire. All things being equal, I'd recommend using the one inside the structure if you are doing something inside the structure, and the one outside the IPE structure if you are just merging the error (or presumably the warning) from outside.

Each bordernode (whether data value reference or other) on the IPE structure acts independently (with the exception of order of execution which is ordered to prevent deadlocks). Thus, each pair of bordernodes generates a single, unique error which may or may not be handled. If you wire one pair of bordernodes, but not the error terminals for the other pair, you could trigger auto error handling. Each read/write pair can generate its own errors depending on the state of THAT reference.

Since any number of bordernodes could be present, as well as any number of calculations could be done inside the IPE structure, we do not "fail" out on the IPE. If a data value reference has an error accessing the reference (a fail other than just a wait until the lock is available), a default value is placed on the de-referenced wire. All other calculations in the IPE are performed as usual and we simply discard the value wired to the write/unlock bordernode for the DVR with an error. If you are doing a calculation that takes time or referencing a data value reference that is likely to fail, I highly recommend putting a case structure inside the IPE and act according to whether the border nodes have an error. Actually, this is part of why we don't have an error-in terminal on the bordernodes, because even if they individually fail, the structure continues. Forcing one of them to "take a fall" because of an external error didn't seem to be the appropriate behavior.

The two error terminals of the read/write (lock/unlock) dvr border nodes deliver identical errors. Thus, it is never necessary to "tunnel out" the errors from the lock/read border node as done in the first post's code. Also, technically the write/unlock node does nothing but release the DVR's lock and thus cannot return any new error.

As for the lack of input error terminals, there was confusion as to what the behavior would be if an error were wired into the read/lock DVR border node (the write/unlock would continue to simply release the lock). Should the nodes ignore the error but add it to the error out? Should they not lock the reference but instead create a default value on the wire? mje has a good discussion. In the end, even if perhaps it wasn't the most usable design, we wanted the behavior to be clear for the nodes, so we omitted the error-in terminal.