LabVIEW
Impressive processing slow down due to UI refresh
Solved!
@BrainDrain wrote:
Hi, I just found your question, when I was palying around with references for speeding up a graphical display.
As metioned before, the fastest update mechanism is using references. If you would write the information directly into the reference to your table display, the UI is updated instantaniously. Just have a lookat the screenshot below. The Vi on the left generates numbers and they are written into a property node of a reference. In my case the reference refers to an waveform chart that is part of an ohter application. Therefore, the reference is handled by a global. If the value is changed on the left, the display immediatly updated on the right. Yes, there is no loop running on the right. But is does not matter. The display is updating even the vi is not executing as long the global contains the right reference!
To cut a long story short: if you directly write your array values into the appropriate reference, you don't have to wait for any UI update... so the update time should be the same as the array update time... without any further delay...
Best wishes,
Luke
What is in the Variable_Global? I tried to put there a reference of "Waveform Chart" on the middle window, but an error pops up.
@Kochise wrote:
I had this in a shady corner of my mind for a while,
it took dust because that requires a large refactoring
and I'm afraid doing it with Labview. A text based
programming language offers far more flexibility
in that matter.
David Koch
Not really my experience! In both cases it depends on the architecture of the software. That this feels such a big task simply means, that you either have employed a less than good design or that you are afraid of something that isn't there. LabVIEW code can be written just as moduler as text based code and offer similar refactoring costs.
One of the problems with LabVIEW is, that it is so easy to start with that many people that would never think about writing a C(++/#) whatever program will do so in LabVIEW and use pretty bad design archiitectures. And if you come from text programming, it is easy to paint yourself into a corner by trying to apply certain text programming specific patterns.
Well, if you talk about such a simple change that regexp copy/paste will just work, you certainly have somethinig much simpler in mind than rearchitecting the UI display to be more performant for such a test data structure.
But that loop doesn't really need to be a huge monster if you use some proper state machine architecture. It's the same about copy/[pasting a multipage C loop into another part that has many application global and module global references for all kinds of hidden interdependencies.
Of course LabVIEW has it's pain points, just as C or C# has its own, but a LabVIEW program doesn't need to be a pitta in itself. It can be made in one however, but that applies for any programming language.
The small part of the diagram you show in the first post, clearly hints at a monster architecture with about 10 huge loops inside each other. That such an architecture is hard to restructure, I believe you immediately. But in C(#) you wouldn't have written a main() with 10 loops inside each other that span about the entire source code of your program. That would make it even more unwieldy than the LabVIEW program you now have.
