LabVIEW
Shift register for continuous count
Hello,
I am checking this string value (red marking) in the entire string what is send. If the string which I am looking matches means, my LED will glow or it won't. I want to note down how many time does my LED blink. I was using Comparison -> Select block to count the value. it's not counting continuously. If the string which I am looking appears it starts to count, once it disappeared the value not remains in the last count, it falls back to zero and starts again. I want to read it from the last count.
Please give me your valuable solutions.
Thanks in advance,
JrEngg
Hi,
Without the full VI and only with assumptions, what does it do when you wire the register shift wire without that +1 to the False side of the select block ?
Here a quick proposal
I'm not a fan of PtByPt VIs, but "Increment PtByPt.vi" does that OoTB.
Use QD to find it.
Since the PtByPt VIs are reentrant VIs that keep state (you can look into the VI to see how), you can't use PtByPt to work on items in an array, or in sub VIs that you use in several places (unless the parents are clones too).
But for your case, "Increment PtByPt.vi" will work well.
Search LabVIEW like a graph! 
@jrengg wrote:I am checking this string value (red marking) in the entire string what is send. If the string which I am looking matches means, my LED will glow or it won't. I want to note down how many time does my LED blink. I was using Comparison -> Select block to count the value. it's not counting continuously. If the string which I am looking appears it starts to count, once it disappeared the value not remains in the last count, it falls back to zero and starts again. I want to read it from the last count.
Please give me your valuable solutions.
You talk about a shift register in the subject, but then you are showing us a severely truncated picture that does to not even contain a shift register. Then you talk about counting, but using orange wires instead of integers.
You also need to define the term "blink", for example if it remains TRUE for five iterations, is that one "blink" or five "blinks"?
Since we don't see the entire code, we don't even know if you actually have a toplevel while loop (good!) or just using the "continuous run" button (bad!).
If you simply want to count how many iterations the comparison is TRUE and you actually have reasonable architecture, the following would work (If the count is expected to exceed ~32k, a little more code is needed):
@altenbach wrote:If you simply want to count how many iterations the comparison is TRUE and you actually have reasonable architecture, the following would work (If the count is expected to exceed ~32k, a little more code is needed):
Change that constant to a U64 and you'll be safe for at least a few dozen decades.
wiebe@CARYA wrote:
@altenbach wrote:If you simply want to count how many iterations the comparison is TRUE and you actually have reasonable architecture, the following would work (If the count is expected to exceed ~32k, a little more code is needed):
Change that constant to a U64 and you'll be safe for at least a few dozen decades.
I would consider that "a little bit more code", because we also need to change the representation of the indicator 😄 (... and then another little bit more code is needed to get rid of the benign coercion dot if desired.)
@altenbach wrote:
wiebe@CARYA wrote:
@altenbach wrote:If you simply want to count how many iterations the comparison is TRUE and you actually have reasonable architecture, the following would work (If the count is expected to exceed ~32k, a little more code is needed):
Change that constant to a U64 and you'll be safe for at least a few dozen decades.
I would consider that "a little bit more code", because we also need to change the representation of the indicator 😄 (... and then another little bit more code is needed to get rid of the benign coercion dot if desired.)
I couldn't know that that indicator isn't set to 'adapt to type'! 😂
