From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-09-2018 02:54 AM - edited 07-09-2018 02:57 AM
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.
07-09-2018 03:08 AM
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.
07-09-2018 03:39 AM
Well, a type cast or (preferred AFAIC) a concatenating build array (doing nothing, hopefully even compiled out) are workarounds.
07-09-2018 04:01 AM
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.
07-09-2018 05:49 AM
@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?
07-10-2018 11:19 AM
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.
07-11-2018 04:10 PM
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.
07-27-2018 11:22 AM
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.
07-29-2018 05:24 PM
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.
08-15-2018 11:06 AM
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.