cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Bug in In Range and Coerce when used with malleable VI

Solved!
Go to solution

Re: Bug in In Range and Coerce when used with malleable VI


 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 17
(277 Views)

Re: Bug in In Range and Coerce when used with malleable VI

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 17
(270 Views)

Re: Bug in In Range and Coerce when used with malleable VI

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

Message 13 of 17
(265 Views)

Re: Bug in In Range and Coerce when used with malleable VI

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 17
(256 Views)

Re: Bug in In Range and Coerce when used with malleable VI


@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 17
(247 Views)
Highlighted
Solution
Accepted by topic author Florian.Ludwig
07-13-2018 12:02 AM

Re: Bug in In Range and Coerce when used with malleable VI

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 17
(224 Views)

Re: Bug in In Range and Coerce when used with malleable VI

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 17
(184 Views)