LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in In Range and Coerce when used with malleable VI

Solved!
Go to solution

 wrote:

and using the output of a VIM (with an input that is not well-defined) to define the shift register type doesn't sound like something that should work.


In none of my screenshots, the output of the .vim is used, and it's still broken!

 

If manually setting the compare output works, I'd say we have a workaround.

Message 11 of 21
(1,614 Views)

Update:

Replacing the SRs with FNs and wiring their initialization inputs does not fix the issue.

 

Manually setting the compare mode does not unbreak the wire, except when setting to the (in this case undesired) setting of compare data sets.

Thus, it is unfortunately not a workaround here.

0 Kudos
Message 12 of 21
(1,607 Views)

Well, a type cast or (preferred AFAIC) a concatenating build array (doing nothing, hopefully even compiled out) are workarounds.

Message 13 of 21
(1,602 Views)

True. I have actually employed this, as you kindly provided it as a workaround in your first snippet.

Additionally, I could have gotten the code to work without the VIM.

I'm still hoping to have the issue looked into for future releases of LabVIEW though.

0 Kudos
Message 14 of 21
(1,593 Views)

@Florian.Ludwig wrote:

 

I'm still hoping to have the issue looked into for future releases of LabVIEW though.


Definitely. I'm a bit surprised that this didn't came up sooner. It's seems like a pretty common situation. Apparently you're the first to try the combination uninitialized shift register, compare, .vim...

 

I think the right people are already reading this thread?

0 Kudos
Message 15 of 21
(1,584 Views)
Solution
Accepted by Florian.Ludwig

CAR 704907 filed.

Looks like I must not be propagating the ephemeral flags correctly. Types are marked as "ephemeral" when we aren't sure and are just guessing at their types -- like what originates from an uninitialized shift register. If the flags propagate correctly through all the nodes that can polymorph, they'll cause LV to recompute those types on a second pass through the loops. Seems that isn't happening right. Not sure why at this time.

 

The insertion of the Type Cast node to explicitly set the type is a correct workaround.

Message 16 of 21
(1,561 Views)

AQ: just wondering whether the Malleable VI behaviour I posted on LavaG here is related - it shows a similar non-propagation of type, resolved in my case with an enclosing sequence structure.

Message 17 of 21
(1,521 Views)

GregS: I don't have the bandwidth to investigate. As you can see from the length of time it took to even get back to your forum post, my time for side-adventures has become extremely limited lately. If you think you've found a bug, please report it to NI -- an AE can triage and let you know if it is actually a bug. I'll add the link to look at when I look at the CAR already filed (probably sometime in Q3 when I get to most of my backlog 2019 CARs).

 

Basically, the official roles I've taken on lately have nearly eliminated my spare bandwidth for direct customer support for the foreseeable future. Overall, this is a good thing, but it does impact this sort of forums work.

0 Kudos
Message 18 of 21
(1,324 Views)

AQ: I always thought your forum work WAS your most important work.  Oh well, back to reading tea leaves to work out what's going on....

 

Seriously, thanks for all you've contributed in the forums in the past, particularly if it was additional to your REAL job.

0 Kudos
Message 19 of 21
(1,311 Views)
Solution
Accepted by Florian.Ludwig

Found the issue... both issues. 🙂

 

Yes, there was a bug with malleable VIs: deep corner case. When a loop has uninitialized shift registers and contains polymorphing nodes, we have to repeatedly re-run the type propagation until it settles. For any given loop, settling the types can take between 1 and K iterations, where K depends on the number of shift registers and polymorphic nodes involved. K is a maximum... the loop might settle sooner than that. When the malleable VIs were inside loops that needed the maximum number of iterations to settle the types, they weren't adapting on the last iteration. So I fixed that.

 

But the real fun was finding a bug that predates my employment with National Instruments. Turns out the In Range & Coerce node has had a rare and subtle problem with ephemeral bits (see my previous post) forever -- the bottom output can be either a scalar Bool or an array of Bool depending upon the inputs, but it was claiming to be certain of its type more often than it should. It wouldn't affect most diagrams -- it just pushed loops to type prop the full K times more often than necessary, but that was pushing the malleable subVI into issue #1. No where near the oldest bug I've found and fixed, but pretty far back.

 

These fixes will be in LabVIEW 2018 SP1.

Message 20 of 21
(1,287 Views)