LabVIEW
Malleable VI broken wires... NOT!
@1984 wrote:Any reason to this and is there a way to solve this in an automated way instead of going into every broken VI and reconnect wires? (tried ctrl+RUN VI button, but that didnt help)
Malleable VIs are neat, but are indeed a bit erratic...
This shows esp. with nested .vims. (YMMV)
It depends a lot on the LabVIEW version. This is one area where things seem to improve without notice. (YMMV)
A type specialization structure around a .vim call inside a .vim seems to improve the behavior:
Put an unwired add (or increment) in the other case, so it always breaks...
This should be a no-op, but it seems to help (although again, it's erratic). (YMMV)
Sometimes Save All seems to fix things... (YMMV)
Search LabVIEW like a graph!
@1984 wrote:
I pretty sure thats the most YMMV in a single post I've ever seen 🙂 Thanks for the info!
YMMV!
That's on the malleable VIs, not me!
@1984 wrote:
Recently I have converted fair amount of VIs in my project to malleable. What I have noticed is that some of the VIs using malleables became broken because the wires connected to the malleable VI got broken. Once I disconnect and reconnect a wire it is not broken anymore, it seems I only needed to rewire them. I can't provide an example, but I have noticed this in several cases so I guess its a common phenomena.
I've had that happen a few times, typically when upgrading LV if memory serves and a couple times when LV crashed (which doesn't happen as often nowadays)
@1984 wrote:
Any reason to this and is there a way to solve this in an automated way instead of going into every broken VI and reconnect wires? (tried ctrl+RUN VI button, but that didnt help)
What version of LabVIEW are you using? I know this was a major issue in the compiler that many were up in arms over. I'm mostly certain it has been fixed. I don't remember exactly what versions were involved and too lazy to go digging.
wiebe@CARYA wrote:
@1984 wrote:Any reason to this and is there a way to solve this in an automated way instead of going into every broken VI and reconnect wires? (tried ctrl+RUN VI button, but that didnt help)
Malleable VIs are neat, but are indeed a bit erratic...
...
A type specialization structure around a .vim call inside a .vim seems to improve the behavior:
That's interesting- I recently had an issue where a VIM inside a TSS inside a VIM was corrupting things, and getting rid of the VIM inside the TSS actually fixed my "This VI will not compile" error. I'd fix it, save everything, close, and reopen it and bam it was corrupted again.
Of course it could've been a coincidence and some minor element was corrupted, so.... YMMV 🙂
@BertMcMahan wrote:
wiebe@CARYA wrote:
@1984 wrote:Any reason to this and is there a way to solve this in an automated way instead of going into every broken VI and reconnect wires? (tried ctrl+RUN VI button, but that didnt help)
Malleable VIs are neat, but are indeed a bit erratic...
...
A type specialization structure around a .vim call inside a .vim seems to improve the behavior:
That's interesting- I recently had an issue where a VIM inside a TSS inside a VIM was corrupting things, and getting rid of the VIM inside the TSS actually fixed my "This VI will not compile" error. I'd fix it, save everything, close, and reopen it and bam it was corrupted again.
Of course it could've been a coincidence and some minor element was corrupted, so.... YMMV 🙂
I don't think it's corruption, at least not of the VI. It's just that .vims behave in ways we don't understand.
I've had complex .vim schemes that didn't work at all, and after changing some code worked perfectly. No idea what I did to deserve it...
Another factor is the compile cache. There could be some misalignment between code and the cc, triggering updates too much or too little (or too soon or too late).
@BertMcMahan wrote:That's interesting- I recently had an issue where a VIM inside a TSS inside a VIM was corrupting things, and getting rid of the VIM inside the TSS actually fixed my "This VI will not compile" error. I'd fix it, save everything, close, and reopen it and bam it was corrupted again.
A VIM inside of another VIM is a known issue. It is not 100% going to break things, but, anecdotally, seems to be very commonly causing issues. I'm pretty sure Darren N talked about this in his Ludicrous Ways to Fix Broken LabVIEW Code presentation. Granted, he goes full-bore "avoid VIMs like the plague".
