LabVIEW
BUG Block diagram cleanup fails completely? Generates very bad results
@sth wrote:
@billko wrote:
I can only guess that he doesn't mean that they literally break, but that they make some funny turns even when they apparently don't need to.
No, they break. I have had cases where BDC will leave dangling bits of wires. It was a really ugly diagram (not mine). I have been getting used to BDC as a quick way to make reasonably readable code. It has its oddities but it does save a lot of moving things 1 pixel at a time.
You can speed that up by a factor of 8 with Shift+Arrows
@JÞB wrote:
@sth wrote:
It has its oddities but it does save a lot of moving things 1 pixel at a time.
You can speed that up by a factor of 8 with Shift+Arrows
Yes. I use the shift-arrows a lot!
But to get the final alignment is the slow part to remove every last kink in the wires. That is the slow part with a lot of key strokes. I tend to be a little OCD on the diagram layout that I am trying to focus my time on working code and convince myself that BDC is "good enough".
@Dhubbell wrote:It seems with every New Release of LV, the BDCT gets worse. I subscribe to LV Updates and keep updated with the latest version of LV. LV versions earlier than 2013 seemed to work without any problems. 2013 had a few problems, but, was manageable, 2014, and 2015 went off the charts and has literally BLOWN UP my code.
I like how many people say "write better code". They must not live in the real world, where date/time/projects must be met quickly. I mean if I take a simple block of code, that fits on one screen, and when I use the BDCT it folds wires under its self, and breaks other wires...where's the usefulness? Most of the time I plop code down grabbing parts and pieces...you know how it goes...then a simple BDCT should clean it up. BDCT worked before, but, now it's getting worse, and not better.
I've opened CARS and sent sample code to NI. I've been told it's complicated and they have no idea when it will be fixed. Great answer. I see people reporting this problem since 2010 and here it is 2016...SIX YEARS later and still no answers.
I really like how NI will demonstrate code that has 6 wires with 1 structure and say look how good the BDCT works! Unfortunately, there are more than 6 wires, and 1 structure in most BD.
I use two monitors to code and if there are LIMITS that NI must implement, then they should be implemented so the BDCT works. Don't give me an unlimited canvas to paint on, then tell me sorry it's your code.
THE BDCT IS LONG OVER DUE FOR AN UPGRADE. When BDCT works, it's a great time saver! When BDCT doesn't work, it wastes more of my valuable time.
Apparently NI doesn't feel BDCT is important to its customers. I guess I'm the only one that feels the BDCT should be a priority and it shouldn't take over 6 years to fix.
People always say "write better code" because that's just what you should do. "Quick and dirty" leads to a mess I'm probably going to have to untangle when they hire me to clean up your mess. (And believe, me, that's a big part being a LabVIEW contractor - cleaning up ohter people's messes.)
You can code both quickly AND cleanly. You have to stick with it, though, because you start out slowly, but you regain all you lost - and them some - when coding the "big app" consists of simply stringing together stuff you took the time to do correctly.
And of course, this leads to less "plopping down of code".
