fpga--counting inside a case statement

[cstakac]

Hello, LV Users--Kind of intermediate with LV, pretty new to FPGA.  I'm using LV2010 with FPGA add-on with a PXI RIO 7852R.  I have my FPGA app working for all practical purposes with the exception of a decision point  that is controlled by a (what-I-thought-should-be) simple integer count.  This integer count I tried at first with shift registers, then tried a feedback node as I saw that had been used in FPGA Debug.lvlib back in 2008.  STILL doesn't work!  What happens in my code is this:  Every time I detect the most negative point in my modulating waveform, a boolean goes True and enters a case where my count should be updated by 1.  Instead of being updated by one, it is being updated on the order of 10,000 or so, the same number each time +/- one.  Not sure where this number is coming from!  A tick count, perhaps?  It is a bigger number if I slow down my modulating waveform.  Any idea why this would be happening?  Better yet, any ideas how to make a "simple" count work as hoped for?  Thanks very much for all help.

[Blayne_K]

Hello Cstakac,

Without seeing your code my best guess is that your threshold triggering logic is likely configured such that your increment count case is entered multiple times between each cycle of the waveform. Is it possible that your Boolean logic is not being set to false once you have referenced the triggering condition on your waveform acquisition?

If you are fairly confident that is not the case, could you please post a screenshot of your threshold logic and your increment case in your case structure.

Best,

Blayne Kettlewell

[cstakac]

Thanks, Blayne.  Here is what I'm doing.  I do set the boolean to false in the in-between moments.

[Blayne_K · Accepted solution]

Out of curiosity, when the SaddlePtCount is true, does it prevent you from reentering the 0.08Hz, 0.0159 case? If you are not prevented from reentering the case then your increment count will continue to increase while your modulated signal is in the bounded range of +- 0.0003055. To test this possibility you could decrease the bounded range to say +- 0.0001 to see if this decreases the count. Depending on if this works, all you would need to do to prevent the retriggering of the counter would be to have a local variable "Triggered" that is set true the first time the SaddlePt boolean is true. Then, if you wrap the feedback node increment in an additional nested case structure, you would check the "Triggered" condition and if it was false set it true and leave the true case in the case structure blank. Hence, the first time the count will be updated while each successive time the signal is within the bounded range in a given cycle it will not change the count. The only other modification would be to set the "Triggered" variable false when the SaddlePt is false.

Hope this helps,

Blayne Kettlewell

[cstakac]

You were absolutely right, Blayne!  I didn't think it could have been generating that many points, but that is what it turned out to be.  Your solution was right on, and I thank your for it.

[RavensFan]

Then mark Blayne's message as the solution to your problem rather than your own thank you message.  You can unmark yours as the solution by going to the options menu to the upper right of your message.

I'm sure he would also appreciate a Kudo. 

[cstakac]

Thanks for the tutorial.