LabVIEW
Creating a progress bar
It's not bad at all.
You can make it better though by simply straightening some wires, making sure they are not going from right to left:
Before:
After:
The error coming out of obtain notifier doesn't really do anything. If there is an error obtaining the notifier, the reference is invalid and the Waits will throw an error anyways.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
It's not bad at all.
You can make it better though by simply straightening some wires, making sure they are not going from right to left:
Before:
After:
The error coming out of obtain notifier doesn't really do anything. If there is an error obtaining the notifier, the reference is invalid and the Waits will throw an error anyways.
I agree that it stands quite well on its own. The main thing is that you can tell that a lot of thought was put into making it readable. It's mostly about personal preferences here.
FYI, code neatness isn't just about being anal; it is essential, especially when creating complicated code. (It really shouldn't be too complex, but that's a discussion for another time.) The reason for this is essentially the same as the reasons for using regular indents in text coding: It doesn't matter to the compiler that you have random indents, but if someone came looking for you because he wanted to strangle you for using random indents, I'd point to your desk and go to lunch so I could have some plausible deniability. Keep the wires as straight as you can, don't have them running behind stuff, don't have objects hiding behind others, stuff like that, and it will be easy to read, easy to maintain, and easy to troubleshoot.
Why. So. Complicated???
- A FOR loop with a termination condition will stop after all iterations have completed, so the lower comparison is pointless.
- You do calculations on all integer DBL constants to create an integer. Maybe there is an all-blue solution. It also belongs before the loop (even though the compiler will treat it as loop invariant code anyway).
- Not sure what the point of the lower loops is. A 1s wait and a 1ms timeout seems contradictory. I don't think you need that loop at all (but I defer judgement until I see the bigger code).
- You don't really need to wire the high resolution seconds across the loop. You really also don't need to take a reading with each iteration if all you are interested in is the last value.
- Shouldn't "meldung" have a different mechanical action?
Maybe all you need is the following (It even updates the elapsed time with each iteration):
I would also suggest to make the progress bar invariant to N so it goes to 100% over all outer iterations no matter what's wired to N. One possibility:
@altenbach wrote:
I would also suggest to make the progress bar invariant to N so it goes to 100% over all outer iterations no matter what's wired to N. One possibility:
I just use a Property Node to set the Scale->Range->Maximum to be N-1. I can then just wire the FOR Loop's iteration terminal directly to the indicator.
@crossrulz wrote:
@altenbach wrote:
I would also suggest to make the progress bar invariant to N so it goes to 100% over all outer iterations no matter what's wired to N. One possibility:
I just use a Property Node to set the Scale->Range->Maximum to be N-1. I can then just wire the FOR Loop's iteration terminal directly to the indicator.
In most cases, I show the digital display too, so this won't work 😄
As I said, you could just place the stop button inside the inner loop. In a pinch, even a local variable might work.
If your problem are in different code, maybe you should show us that. It is possible that you have some dataflow problems. How longs is one iteration?
