LabVIEW
BUG Block diagram cleanup fails completely? Generates very bad results
@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
I know that, but I mean literally 1 pixel since the BDC always leave these little 1 pixel bends in the wires that annoys me. Actually if you grab a chunk of code and move it with Shift-arrow it can move different items a different amount. It may move them to a multiple of 8 location which is not always what you want.
The fact that it breaks the diagram is more of an issue, but in all cases that I have found this to happen, it is just dangling wire branches that can be corrected with a delete bad wires command. However I do worry that will delete something important.
As to the quality of the BDC, it is not as good as a human optimized chunk of code. Never will be. What might be nice is the ability to permanently mark parts of the diagram as "locked" and not available for BDC. A small blue outline around those items? Too much visual clutter. But that can allow for the BDC to optimize just the new sections as you add code and treat some of the regions as fixed blocks. This is sort of like a word processor to learn the spelling of words that are not in the dictionary like magnetocaloric and other useful terms. So they don't get flagged by the spell check or don't get reshuffled by BDC.
@Dhubbell wrote:
@mikeporter wrote:
Seldom have I seen someone so precisely state the cause of their problem:
"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."
Actually I have been doing this work for 30 years, and no, I don't know how it goes. It's been 3 years and you still haven't learned to take responsibility for the problems that you created yourself. You hack things together and then complain about the tool you are using.
Perhaps you need to find a line of work where the quality of workmanship doesn't matter.
Mike...Let's not go down that path trying to belittle another's style of programming.
The simple fact of the matter is the BDCT doesn't work.
I've seen some correlation to the problem.
Since you've been in LV for 30 years, then you too have noticed the flat sequence colors change…the older versions of the flat sequence had a DARKER gray, the new versions of the flat sequence are a LIGHTER gray.
The BDCT started failing when the NEW Lighter Gray Flat Sequences starting appearing.
I too have been around the block a few times with LV. All I can say is the BDCT used to work brilliantly, but, in the last 4-5 years it's really gone downhill.
I'd like to find a solution and bring the BDCT back to its original glory. It's a powerful tool when it works.
You could always go back to the version of LabVIEW that you feel most comfortable with.
Really, you should just stop using the BDCT as a crutch.
My mantra always was: "If the BDCT makes your BD look better, you're probably doing it wrong".
I think I failed to note the "smaller VIs" part of your complaint. I'm not sure what "smaller" means to you, but to me, smaller means something like "I just created a subVI from selected code and it's a bit jumbled up". If that's the kind of stuff it's failing on, then that's a problem.
Maybe it was affected by all the new ways you can stretch and shrink your BD empty space. Unfortunately I have no answers there.
Hi Dhubbell,
It is clear that you have identified problems with the BDCT. Hopefully NI will make improvements.
FWIW, I have a suggestion about dealing with sequential operations. I appreciate the ability to see all of the steps involved in the sequence, but it can take up a lot of BD real estate. Obviously, creating subvis would be a pain because of the front panel interactions.
A "For Loop Sequencer" with descriptive step names is an option worth considering. Using the Conditional Terminal (not shown) allows you to deal with errors that might occur in the process.
