How to get specific pulse train

[colorizedice]

Yes, I know it's kind of weird. At the beginning, I also think the reading after division should be just the number of pulse-pairs, but practically, it's not. So I designed a demo vi (shown in the attached vi), which is when I received the 'n' pulse pair, it will output a string of "step n".

Theoretically, if I have 5 pulse pair, it will output "step1", "step2",...,"step5", but actually, it will randomly output "step1", "step2", "step2", "step3", "step3", "step3", "step4", "step5". That is what I said "repeat at some step".

So I want to get a way just count the first pulse in the pulse-pair, rather than use divider afterwards.

Thank you very much for your rely.

[BertMcMahan]

I see, so you're seeing the Queue trigger too frequently. I think your example should work- if you compare the newest value with the oldest, it should only generate the Value-Signaling event when it changes.

I would suggest cleaning up your code a bit though. Instead of generating a Value-Signaling event inside the case structure which then enqueues a value, just enqueue the value inside the case structure.

[Kevin_Price]

Honestly, you're drastically overcomplicating this.  There is no immutable law requiring that every value you query from the counter task must be reported to the other parts of your software.  *YOU* get to decide whether or not to pass that reading along.  *YOU* can decide whether to pass the raw count or the calculated "int(count/2)".  *YOU* can decide whether to round up or round down when you query an odd raw count value. 

By making such decisions, *YOU* have control to make sure you don't send repeat information.  All you need is some simple software math and decision logic.

-Kevin P

[colorizedice]

Yes, I'm "seeing the Queue trigger too frequently", which means even the value of "number of count" has not been changed, there still is a trigger event generated. I guess that abnormal trigger is due to the division operation.

Presently, I set the wait time inside the while loop the same as the pulse-pair generating time gap from ECU, by this operation, it solves the problem.

However, I still think there should be some better way or direct way to do this thing.

[Kevin_Price · Accepted solution]

While I agree with BertMcMahan that there are some other things about the code that could stand to be cleaned up, the essence of what you need to change is seen below.  Round up and convert to integer before comparing with previous.  That's all.

Here's an example of what you might see from one iteration to the next.  Raw Counts might repeat.  Or you might miss some.  The calculated result might repeat.  But you only report when there's a change to the calculated result.

Raw Count      Ceil(Raw/2)       Report?

       0                       0                     F

       1                       1                     T

       1                       1                     F

       2                       1                     F

       2                       1                     F

       2                       1                     F

       3                       2                     T

       4                       2                     F

       4                       2                     F

       6                       3                     T

       8                       4                     T

       9                       5                     T

      10                      5                     F

-Kevin P

[colorizedice]

Thanks a lot for this advice. It works for my hardware!

BTW: Is there a direct way for me to just count the first pulse and ignore this second one?

[BertMcMahan]

@Kevin_Price, could you explain why his floating point comparison didn't work? If he's getting false triggers, it would mean that the same floating point value was being coerced differently in different runs. I know it's typically unsafe to use an "equals" condition on floating point numbers, but in this case (where they're coerced from U32's), it should be the same, no?

I'd have him run his code, and in addition to displaying "Step n" it would say "Step n, last pulse count = x, current pulse count = y" so he could see what's triggering his event case.

[Kevin_Price]

@BertMcMahan: the problem with the OP's floating point version was simply that by comparing fractional values, the decision was made to report a value on every raw count change.  However, the *value* that was reported was a rounded integer (there's a coercion dot where the floating point value is written to the Value (Signaling) property).  When the loop ran fast, there were repeats.   Explicitly coercing to integer *before* comparing solves that.  I chose to round up b/c the OP seemed more interested in noticing the 1st of the 2 paired pulses.

@colorizedice:  the "direct" way you might approach this with counter task configuration are inferior to the software version you've got going.  It would be more fragile because it'd depend not only on the *counting* relationship (2 pulses in = 1 pulse out) but also on specific timing properties of the intervals between pulses.  I don't recommend it.  Nevertheless, here's an outline:

To see the 1st of 2 pulses and ignore the 2nd:

Configure 2 separate counter tasks to work together.  The first task is a helper and would do retriggerable single pulse generation.  The duration of the pulse should be long enough to still be active when the original signal's 2nd pulse comes through.  That way your helper task only responds to the first incoming pulse, not the second.   The second counter task would then count the output pulses from your helper task.  It'll give raw counts that increment by 1 after your 1st of 2 pulses while "ignoring" the 2nd of 2.

-Kevin P

[colorizedice]

Thanks for the detailed explanation!

[BertMcMahan]

Ah, thanks Kevin, I see it now. For some reason my brain was adding a "to U32" after the divide and was thinking it was comparing coerced values, not doubles