Wiring error after replacing typedef

[_Y_]

I encountered a problem replacing typedef with script. Simple test answered that the problem is not in scripting but in behavior of the altered BD. So, scripting is not needed to reproduce the problem.

This code does not do anything useful; it only illustrates the question:

 

 

The Case Structure has two cases. The second is here

Now I replace the typedef with new one:

 

But the wiring in second case is broken.

 

Attempt to rewire Wire 2 (i. e. delete it and connect terminals again) doesn’t help. The wire is still broken.

However, if I rewire Wire 1 or Wire 3, the problem disappears; i. e. Wire 2 suddenly becomes functional.

Could someone answer:

• What is the reason for such behavior?
• Could the problem be solved with scripting? Of course, a script can rewire but it seems like a dirty fix.

Attached ZIP contains test code created in LabVIEW 2020 SP 64-bit. The problem is the same with LabVIEW 2021 SP 32-bit.

[JÞB]

This is one of those nasty hidden problems with using the default value if unwired terminal option with uninitialized shift registers and improper initialization.

On first call there is a ref to a datatype which was a brown cluster <numeric values only and hence contiguous in memory>  that you replaced with a pink cluster <non contiguous memory>  then you try to access the pink cluster when the ref still expects brown.

Had you not chosen to use a default if unwired tunnel the code would have broken a bit more elegantly but, still broken properly. 

Basically you can't expect backward type propagation.

[_Y_ · Accepted solution]

---

@JÞB wrote:

This is one of those nasty hidden problems with using the default value if unwired terminal option with uninitialized shift registers and improper initialization.

On first call there is a ref to a datatype which was a brown cluster <numeric values only and hence contiguous in memory>  that you replaced with a pink cluster <non contiguous memory>  then you try to access the pink cluster when the ref still expects brown.

Had you not chosen to use a default if unwired tunnel the code would have broken a bit more elegantly but, still broken properly. 

Basically you can't expect backward type propagation.

---

Thank you, I was thinking about back-propagation problem but was confused with Wire 3 (rewiring Wire 3 removed the error).

After your post, I suggested that combination of the  uninitialized shift register and hidden default (Use Default if Unwired) would be too much for LabVIEW internal intelligence. Such modification of the code solved the problem:

Unfortunately this solution is specific. It cannot be used as general.

[JÞB]

Just to satisfy my curiosity.   Try that old code replacing the typedef cluster with a new brown cluster.  Let's see if the LabVIEW internals are smarter than you think.

[Kevin_Price]

Help me out because I'm not seeing what it is that makes the solution in msg #3 "more specific" than what you were trying to do in msg #1.   Either way, case 0 always creates a new DVR and on first call will also abandon the old map.  The only real difference I see is whether or not "Build Map" gets used, but that doesn't strike me as any more "specific" than the type of the map's value.

What am I missing?

(Note: I tried a different mod to your initial example, using a 0-iteration For Loop in the first call=True case as a trick for passing the map wire straight through while still outputting a default (empty) value.  But I got the same broken wire you had originally.)

-Kevin P

[_Y_]

---

@JÞB wrote:

Just to satisfy my curiosity.   Try that old code replacing the typedef cluster with a new brown cluster.  Let's see if the LabVIEW internals are smarter than you think.

---

Replacing with:

- another typefew containing identical “brown” cluster doesn’t give any error

- replacing with non-typefefined  “brown” cluster doesn’t give any error

- replacing with non-typefefined  “pink” cluster gives any error

By the way, could your recommend reading about handling of contiguous and contiguous memory in LabVIEW?

[_Y_]

---

@Kevin_Price wrote:

Help me out because I'm not seeing what it is that makes the solution in msg #3 "more specific" than what you were trying to do in msg #1.   Either way, case 0 always creates a new DVR and on first call will also abandon the old map.  The only real difference I see is whether or not "Build Map" gets used, but that doesn't strike me as any more "specific" than the type of the map's value.

What am I missing?

---

Sorry, I probably posted unclear message using word "general" in relevance to such kind of problems.

My code cannot be general because it does not do anything. It is illustration, localization of the problem.

---

@Kevin_Price wrote:

(Note: I tried a different mod to your initial example, using a 0-iteration For Loop in the first call=True case as a trick for passing the map wire straight through while still outputting a default (empty) value.  But I got the same broken wire you had originally.)

---

Could you post an image of your solution? I cannot restore you idea from the text description.

[JÞB]

Could you post an image of your solution? I cannot restore you idea from the text description

Just place a for loop.with N wired to a zero and the map wired through.  Since the for loop doesn't execute the data fron the tunnel in buffer is never copied to the tunnel out and it outputs default data.

Don't  ask me to show you how.  Everyone knows that I don't write bugs.

[Kevin_Price]

Here's the 0-iteration For Loop:

Funny, when I just re-did it I found both Wire 1 *and* Wire 2 broken.  I thought I rememberd only seeing Wire 2 broken before, like you.

-Kevin P

[_Y_]

Thank you, I did not think about such use of for loop.

Of course, if this solution works, it is more general then using Build Map.

---

@Kevin_Price wrote:

Here's the 0-iteration For Loop:

Funny, when I just re-did it I found both Wire 1 *and* Wire 2 broken.  I thought I rememberd only seeing Wire 2 broken before, like you.

-Kevin P

---

I had such effect in my tests too but do not remember sequence of steps causing it.