Why is this little VI so slow?

[Joymaker]

The attached VI is part of an application that is operated in two modes:
1. Our special-purpose hardware is attached.
2. Simulation mode: no hardware is attached (used for remote development)
This VI waits until our slides, in two dimensions, have reached their target position. In simulation mode the channel data will always report "ready".

The channel terminals used in the VI are type "Tag", which in my understanding means that they should read the current value, whatever it may be, not waiting for any particular timing of values to be written. But here's how our modes play out: in mode 1, new values are frequently being updated to the channel. In mode 2, the channel is written once and then, after we discover the absence of hardware, never again.

SURPRISE: this VI runs far more slowly in simulation mode! I did a profiling run yesterday and when the app is running slowly, this VI takes the lion's share of the time! Vastly more than the 5 ms wait would account for. Further surprise: I tried burying the channel terminals in a Case structure that would ignore them when the hardware is absent. Timing didn't change!

Is there something about Tag channels that I haven't read clearly, that I need to understand better? Could something else be going on?

[GerdW]

Hi Joy,

the tags aren't created for me, but your VI could be changed to:

(Unfortunately that change will not solve your issue…)

I would use notifiers instead (doing most stuff still for LV2011 and LV2017).

[crossrulz]

---

@GerdW wrote:

the tags aren't created for me

---

That is due to the Type Def that is used inside of the tag data.

---

@GerdW wrote:

I would use notifiers instead (doing most stuff still for LV2011 and LV2017).

---

Notifiers, Global Variables, Action Engines.  These are all alternatives, each with their own list of pros and cons.

[Bob_Schor]

I've been a Channel Wire Enthusiast since they were a "hidden feature" in LabVIEW 2015.  In order to understand what is causing your Project to work poorly, we need to see the entire Project, especially all of the code that involves the Channel Wires (such as the VI that has the Tag Writer, and the TypeDef that defines the Cluster carried by the Tag Channel).  I'm also curious about the logic you are using to query the two Ready bits.  If some of the data (such as "Ready") are really U8, then use a U8 in the Cluster.  Otherwise, what you really want to do is to test Bit 11 (where Bit 0 is the least significant bit) of two 16-bit registers and stop when both are set. What I would do is to And the two Registers (And will accept a U16 and return a U16), then test Bit 11 directly (skip the Split Number and test bit 11 instead of Bit 3, doing it once instead of twice). 

But let's ask about your question -- how do Tags work, and why might it seem that they don't seem to update properly.  [Note -- without other code, we have no idea what "Mode 1" and "Mode 2" mean].

Here's a quiz:  What would be the result if you wired True to a Tag Channel Writer, connected the Writer to a Reader, and wired a Boolean, Element, to the Reader output?  

Here's a hint -- they are called Asynchronous Channel Wires.  When I run this on my machine using LabVIEW 2019, Element is ... False!  Why?  Well, the Writer and the Reader are not connected by a Data Wire, so by the Principle of Data Flow, the only thing you can say is that "True" will be evaluated before the Channel Writer starts processing.  You have no idea when the Reader processes its input relative to the Writer.  In fact, when I run this with Highlight Execution turned on, I see the Reader start before the Writer, and (correctly) read the (default) value in the Tag Channel, which is (Boolean) False.

I suspect (without seeing your code) that you have something like this occurring.  I've successfully used Tags, but I've tried to avoid what I'll call "Ambiguous Start" conditions (it's not a "Race" condition, exactly ...).

Bob Schor

[Ken_Brooks]

It's not about stale values, I can live with those in this case.  It's about PERFORMANCE plain and simple.  My little VI is a HOG and I don't understand why.

Sorry I can't show you my whole project, because it's full of my employer's proprietary information.

[AristosQueue (NI)]

I don't know of anything that should be a hog. The Tag channels are pretty speedy generally.

You say this only happens in "simulation" mode... is that your simulation or LV FPGA simulation mode?

[Ken_Brooks]

That's my "simulation" mode in which the Tag channel has a default value and never gets updated because there is no hardware attached.

[Bob_Schor]

I suggested one way that you code might not work, but can't test it because we don't have enough information to understand your isolated VI -- we don't even know the type of the Tag Channel (though I can see it is a Cluster of 7 elements).  In particular, we can't see the Writer, and when and how the Writer(s) are invoked.  Clearly there is something "different" between the "real" and the "simulated" mode, which we can't see.  The problem is almost certainly there.

While we might not be able to pinpoint the problem if you were to compress the folder containing the entire Project and attach the .zip file, we can certainly give you more information than if you attach nothing useful ...

Bob Schor

[AristosQueue (NI)]

---

@Ken_Brooks wrote:

That's my "simulation" mode in which the Tag channel has a default value and never gets updated because there is no hardware attached.

---

I tried to come up with a theory... couldn't come up with anything.

The channels are written in G. You can open up the endpoint VIs and add some logging to them to figure out where it is spending all its time for you. Maybe you're writing to it when you don't think you are, just writing the same value repeatedly?

[santo_13]

Since the code is confidential, would you be able to recreate the similar reproducible architecture with few VIs?

This would help us to look into how the write and read are invoked.