Can you please post your complete project so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
Another solution would be to use a counter component, UDB based for which you can select automatic reload at capture or TC.
Thanks for getting back to me. The settings aren't really the problem, it's the missing ability to reset the counter in the timer upon capture. The obvious solution would be to, set the counter to the period, start the counter (or have it running continuously), capture the counter contents upon an event and be able to reset the counter to the period, to allow the start of timing to the next event (rising edge, in this case). There doesn't seem to be any smooth way to do that. One can capture and save a 'last', then capture the next event and do the math to find the difference as you would do here between the period and captured event, but without a reset, one must deal with the rollover at zero. Meaning, dealing with subtracting a negative number in the one special case of the roll over. i.e. one event happens before TC and the next happens after the TC and now the last is smaller than the current and the difference is greater than it really is, meaning some sort of two's complement technique for the special case. It's what I'm likely going to have to do, but thought I'd see if anyone saw something I did not or had a trick way of doing it.
I spoke to a CyPro friend/acquaintance/resource about this last night and his take was, that I was right, there isn't a simple way to handle the rollover (like a reset would solve) without using the hardware reset (no API), which, adds another signal to drive the reset and adds a measure of inaccuracy to it because of the 3 cycle delay after reset before the timer restarts (not that that is a big deal in this case).
There is a bit of a proprietary nature to my project, so don't want to post the entire project and the time to re-create just this piece of it is likely more time consuming than just bulling my way through the problem. If anyone that has used the Timer component for processing a tach signal like this and noted this problem has any suggestions, I'd be appreciative.
Dutchman Electronics LLC
Forest Grove, Oregon
image002.jpg 3.4 K
I finally found a link to a user forum where you responded to another user about this precise problem. As the other user did, and as you suggest here, I used a counter component and configured it for capture and TC. I put interrupt pins on both the interrupt and the TC outputs. This allowed me to separately interrupt on a TC or the capture event. In the component config, I set interrupt for only the Capture.
The other problem I was having was getting a count input signal to the beast. I took the suggestion from the other users post (your reply) and added Sync components to counter’s count input. The user had used a DFF, I believe. Clocking the sync at 3kHz and providing a 1kHz clock to the count input set me up for a mSec granularity on a shaft spinning @ 0-1000 RPM (Quadrature Decoder component). Kind of wish the QD component had a counter driven interrupt though, as it sucks to have to do Last/Current comparisons of the count to see if the shaft turned.
Anyway, Thanks for your input and like your other user, sorry that I wasn’t predisposed to sharing my entire project on a user forum. If I hadn’t been time constrained, I’d have clipped out the timer/counter problem child and sent it… although it would have meant sending several configurations that didn’t work.
Dutchman Electronics LLC
image001.jpg 564 bytes