Program scanning with and without shift registers.

[Ganny]

Hello everyone.

I have attached two VIs. The functionality of both VIs is somewhat same, however, in the VI counter_edited.VI as I press the Boolean button, the counter register registers 255 in a single scan (unsigned byte). As far as I can think, it's because, in the single click of Boolean button, the program scans enough times to count 255 in the register. (I can rectify this using a time delay of 1 sec in the while loop) But, in another VI counter.VI, the signal to decision maker is fed through a comparison function. In this case, the counter counts 1 at a time with respect to the Boolean switch press.

Can I know why the difference in two VIs?

Thanks. 

[cbutcher]

The first VI uses the additional check to prevent multiple counts.

The second VI has 'Latch Until Released' as the mechanical action for the button, and no delay in the loop. Effectively, you click too slowly!

Setting the action to Latch When Released removes the behaviour.

[Ganny]

Thanks for the reply cbuthcer. 
Can you please explain how additional check is implemented in the first VI to prevent multiple counts?

[Bob_Schor]

I have several comments about the two VIs you posted to use a push button to step through a loop on each push.

• Did you ever try to run the program twice (in a row)?  Did you notice it doesn't start counting from zero, but from wherever you left off (or 255, whichever is smaller)?  How would you fix it so that it started at zero?
• Do you understand what is meant by "Latch when released" and "Latch until released"?  The first is used all the time (most commonly with Event Loops, with the admonition to "Put your Boolean control inside its Event case" (to make sure it gets read/cleared) -- I can't think when I've ever used the second ...
• Your test in the "Counter" VI works "by accident", and is basically the wrong test to use.  Notice that the question you are testing is "Is this Boolean Value > That Boolean Value?".  Booleans are supposed to have two "values", "True" and "False".  Is True > False?  Is False > True?  The question doesn't really "make logical sense", as the ">" relationship isn't defined for Booleans.  As it happens, LabVIEW represents False by 0, and True by 1, so in LabVIEW, True > False.  Other languages may represent True by -1 (all bits on), so True < False.  
• What is it that you really want to do?  You want to count by one when the Button goes from Off to On, or what would be called a "Rising Edge" of a logical signal.  This happens when the Current Value is True and the Previous Value was False.  As it happens, the (illogical, but accidentally "working") > function does this, as it is True only when the first input is "True" and the second "False".  Both inputs "True" wouldn't work, as True = True, so True cannot be > True.
• A better (meaning "guaranteed to work regardless of how True and False are represented") would be (Current <> Previous) And (Current).  The first condition says "There's a Change" (a Transition), the second that the Change was from False to True.
• Another, rarely used and probably even more rarely understood, function is "Implies".  Implies is False when the First input is True and the second is False, otherwise it is True.  So if you wire Current to the first input and Previous to the second, you'll get the opposite T/F value, so reverse the inputs to the Select function.  Not only will this be correct, use logical functions that don't depend on the representation of Booleans, and use fewer functions, it will baffle those who've not encountered "Implies".

Bob Schor

[Ganny]

Hello Bob.

• I have tried running it twice. It started where it left off. I couldn't fix it yet. Help me in fixing it. 
• I learnt the difference between "Latch when released" and "Latch until released"
• Regarding this point, I get what you mean. This sample code Counter.VI I got this sample code from one of the videos from NI. I didn't feel there was necessity to compare two Boolean value. TBH, when I first coded it, I was not sure if it's going to work at all. That is why I modified the code and ended up with this doubt. Can you explain me why the "Count Register" doesn't get the value 255 just like in Counter_edited.VI even when the mechanical action for Boolean switch is Latch Until Released?

[Bob_Schor]

Shift Registers store values.  After you run the code once, values are still stored in the Shift Register.  Is there a value you want to put into the Shift Register when your program starts?  Maybe 0?  How would you think you initialize the Shift Register with a 0?  Try your idea and see if it works.

Bob Schor

[cbutcher]

---

Ganny wrote:

• Regarding this point, I get what you mean. This sample code Counter.VI I got this sample code from one of the videos from NI. I didn't feel there was necessity to compare two Boolean value. TBH, when I first coded it, I was not sure if it's going to work at all. That is why I modified the code and ended up with this doubt. Can you explain me why the "Count Register" doesn't get the value 255 just like in Counter_edited.VI even when the mechanical action for Boolean switch is Latch Until Released?

---

In Counter.vi, on the first iteration of the loop after you push the mouse button down on the button, the value that comes out of the DI terminal on the block diagram is true. The value coming from the shift register is false, from the previous iteration. As Bob explained, LabVIEW considers True > False, so the result of the comparison is true. This is passed to the shift register.

On the next iteration, your mouse is still held down. The value from DI is true, but the value from the shift register is also true. Therefore, the comparison is false (True == True, not True > True).

In the edited VI, there is no similar check, and so the VI climbs through the values incredibly quickly. There are a great many solutions to this, the simplest of which is to change the mechanical action as you have already discovered. Adding a Wait will seem like it solves the issue, but if you held the mouse down long enough, it would still count multiple times.

[Ganny]

Hello cbutcher,

Thanks for the explanation. I'm pretty much clear with the concept now. Can you explain me how to reset the counter when I stop the execution. i.e., if I restart the execution, counter should start from zero again.

[cbutcher]

Hi Ganny,

Glad to hear you're gaining understanding of the setup. As Bob Schor wrote (paraphrasing wildly) what you currently have is called an 'uninitialized shift register'. That is, you don't specify the value the Shift Register should start with. This is very useful in some situations, but not at all useful in others.

Fortunately, there's a simple solution - just initialize it! Essentially, the shift register holds values through the iterations of the loop. It has two additional connections to outside of the loop. One can be used as an output, taking the last value of the wire from the loop. The other is an input - it specifies the first value. When it isn't wired, the first value is the same as the last value from the previous time the VI ran.

See if you can guess which area you need to wire a 0 constant value to!

[Bob_Schor]

---

@cbutcher wrote:

When it isn't wired, the first value is the same as the last value from the previous time the VI ran.

---

And, if you have never run it, it takes the "Default value" of whatever is contained in the Shift Register.  For numerics, the Default Value is zero.  For Booleans, it is "False".  For Strings, it is an empty String.  For Arrays, it is an empty Array.

A recent post (last 10 days) was generating an Array inside the loop and trying to sum the Arrays in a Shift Register.  Because the Shift Register was not initialized, it took on the default "Empty Array" value, and because Arrays being added are only as large as the smaller Array, the sums were all Empty Arrays!  Initializing the Shift Register to a proper-sized Array of zeros fixed this problem.

Bob Schor