LabVIEW
Recording number of good/bad parts
Solved!
Hey Newton,
You can use a shift register as the one that you already use in your VI. Something like this colud work :
Check the value of your control (TRUE or FALSE) or any of your triggering object, and increment the value in the shift register only if needed 🙂
Hope it helps.
@Newton1878 wrote:
I'm still relatively new to LabVIEW and looking for some help regarding counting the number of good/bad parts in an inspection v.i.
Yes, all you need is a shift register, but make sure the count is an integer (blue). It is bad form to use a floating point (orange) number for tracking counts. You should keep track of at least two of three numbers (good/bad/total), the third can be calculated. In this case, you get the "total" directly from [i] of the outer loop, so all you need is count bad or good.
We can see that you are a beginner, because your code has some very questionable code constructs in your existing code. for example.
- that inner while loop in the "stop" case makes absolutely no sense. It does nothing at all.
- Your state variable needs to be an enum (or adding states later will be a frustrating experience, because you'll need to replace every single existing constant with the new enum). OTOH, you really don't need a state machine for this simple problem.
- You should never delete the label of controls and they should always show on the diagram (stop button, led 1, led 2). Labels are essential for self-documentation. If you want to hide them on the front panel, you can right-click the control/indicator and uncheck "visible items...label". Never erase the label text!
- Formatting the enum value (always=2) into the button text of the failure dialog makes no sense at all. leave the button at the default [OK]. If you want you could format the actual random value into the dialog message instead.
- Since there can only be two results (pass/fail) a single LED is all you need (one state green and one state red)
- Do not scatter the front panel controls and indicators randomly on the front panel. Keep them together. Try to keep the LEDs round. "almost round" simply looks careless. If they should be oval, make them more oval.
- Same for the diagram. Keep things arranged logically, and don't maximize the diagram to the computer screen. A maximized diagram will prevent you from looking at the panel and diagram at the same time, e.g. during debugging (execution highlighting, etc.)
- ...
Of course creating an elaborate state machine is a good exercise, but for the current problem all you probably need is something like this. (The single LED is true=red, false=green, note that I flipped the logic of the comparison). See if you can build it. Modify as needed.
As you can see, it is also useful to label the various diagram constant (right-click...show label) for better documentation. Also keep them in one place. There are harder to find and modify if they are randomly scattered around the diagram. Since they cannot change during a run, it is irrelevant if they are inside or outside the loop.
You can probably guess what's in the other case 😄
@ML927 wrote:
Something like this colud work :
... or simpler ...
(Note that it is often better to have the indicator right after the shift register, else it might show a stale value if the loop contain lengthy code (e.g. an event structure) before a decision on the value is made. Does not apply here of course.)
And yes, that coercion dot is perfectly fine 😄
I did some tests and it seems that the Select version is slightly faster (~30ms vs. ~48ms for the conversion version). Yet, I did the test over 20M increments which I really unlikely to happen here. So I guess that both versions are pretty much the same considering the timing factor 🙂
