LabVIEW
Front pannel jumps a little bit with while loop. What is the problem?
Hello everyone,
I have created a LabVIEW Programm with a front pannel design. The most part of the code are included in a while loop. But whe the programm runs, the front panel jumps a little bit, when everytime it goes to a new cycle. In my expreiences before ,that has not happend. I have just used a milisecond timer. Has anybody idea, what could be the reason?
ps: Could the decoration boxes the reason? (I did not use the decoration boxes before. This time I am using them.)
Thank you very much.
You're going to have to explain a little better what you mean, and including your code would be helpful.
Unfortunately I have not yet upgraded to LabVIEW 2020 so I can't read your code. Could you save to previous version?
Hi Sweet,
@Wintersweet wrote:
pls find my code in the attachment. It is too big to make it as a picture(Screen not big enough). It is programmed with LabVEIW 2020.There are actually many subVIs which are called in this main vi. But I think you don't need them.
…
Do you have better ideas? Thank you very much.
(Better) ideas:
- Cleanup that code!
- Don't use so many property nodes!
- Don't use so many "value" property nodes! (Don't replace them by local variables. Replace them by better data handling and only using the terminals as much as possible!)
- Don't use sequence frames! Don't stack sequences inside of each other! Don't hide even more sequences inside a big loop inside a sequence frame! Ever heard of state machines? (Well you even use additional decorations in the blockdiagram to "organize" your code…)
- Avoid right-to-left wiring (or from bottom-upwarts) like due to those sequence locals…
- NEVER use the STOP or QUIT function in the middle of your VI!
- When you call the same subVI 7 times in parallel ("Lesen SPS Daten") you should think of a FOR loop, which autoindexes an array of parameter strings! (This will be part of "Cleanup" procedure…)
- Uh-oh: in the frame before that you call this subVI 17 times (!) in parallel…
- In the "Relais counter" frame you don't need to stack 3 case structures inside of each other: one case structure can handle all those cases once you wire the blue counter value to its selector input:
- Why do you use "LED" indicators as controls? Bad UX…
- Why do you need to bundle those 7 "mode buttons" into a cluster just to unbundle them in the next frame? Why don't you put those buttons into a cluster on the frontpanel? Why does that missing subVI needs those 7 values as separate inputs instead of just taking the cluster as input? (You might also use a boolean array for those 7 booleans - or even better a radiobutton!)
- When no mode is selected your VI will just heat up the CPU: you don't need to check/poll user input within nanoseconds…
This code is way to large and un-organized to be able to solve any problems in a graceful way…
(@John: you don't want to see this code… 😄)
@GerdW wrote:
(@John: you don't want to see this code… 😄)
@GerdW, from your description of it I would agree. . .
At some point, hacking together code without really understanding best practices is going to bite you in the behind... which is why I don't offer my services as a .NET programmer. 😉
