LabVIEW
Malleable VI VIM input propagation
Solved!
Actually accepted the solution too quickly because the best solution actually comes from mcduff where i can at least use the same 2 outputs with only the top input wired.
LabVIEW 2018 needed to view llb. The save top previous doesn't seem to work with the specialization structure.
wiebe@CARYA wrote:
BTW, one last thing. AFAIK, that "trusted enthusiast" is fixed by the forum. Didn't pick it myself.
I know 😉
wiebe@CARYA wrote:
For me, this one applies (to me, just to be sure) really well: arguing with an engineer...
I love mud! 😉
wiebe@CARYA wrote:
Cheers. If we ever met, I'll buy you a beer (drink it myself if you don't want it
).
I will buy the second and third rounds 😉
wiebe@CARYA wrote:
As for the language nuances, guess you're right. English isn't my first language, so I didn't realize that. Not sure if I can prevent that in the future, nuances take a long time to sink in.
And of course the devil is always in the details 😉
P.S. I will do some introspection...i am not supposed to blow that hard for so little...or am I !? 
@jacemdom wrote:
LabVIEW 2018 needed to view llb. The save top previous doesn't seem to work with the specialization structure.
So earlier that type specialization structure got converted to a disable structure? That explains a bit .
2017 has those TSS, but there are hidden and discouraged. So that's probably why they are disabled for save to previous.
Then again, if I replace the disable structure with a type specialization structure, I can wire two different types to the .vim. Not sure if that's desired behavior? EDIT (Again): that's why I though the select would be needed, to force two matching input types. Doesn't work well, as the input will retain it's type when nothing is wired.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@jacemdom specialization structure got converted to a disable structure? That explains a bit
Reality is a messy business 
That's why i never hold grudges 
@JÞB wrote:
I haven't spent any time on the 2018 new enforce data type vis. Inside a TSS they might offer some powerful insights ... are they open or locked?
Sorry Jeff, still in 17SP1...
The VIMs on the Assert type palette are all unlocked but there isn't much to learn from them as they are pretty basic. The most interesting thing I saw there is this :
The use of 2 type assert nodes to always breakup the code. Nice trick but a simple always break node would probably be faster, quicker and clearer.
@jacemdom wrote:
@jacemdom The use of 2 type assert nodes to always breakup the code. Nice trick but a simple always break node would probably be faster, quicker and clearer.If it existed of course! lol
How about any function? Increment, Decrement, Add, Subtract, Multiply,etc. They all break when nothing is wired to it. Put one of those (unwired) in the last case, and I think you'll get the same effect?
