OP is using a high-speed counter (HSC; cf. Post #8). Do we know if their HSC can generate interrupts?
For no interrupts and monitoring the HSC value in the continuous task, with the raw counter value rolling over once per product (per Post #28) and changing by a few dozen per scan (again per Post #28), there has to be a comparison between the raw counter value and a range of target values.
The original post was
primarily looking for a
"better" way to deal with comparing the un-modified counter value and the target value range when rollover was a possibility i.e. when a simple
Code:
IF (pv >= targetval) AND (pv < (targetval+10) THEN ...
which would not work if targetval was within 10 of the counts-per-product rollover value.
There have been several methods proposed to do this, which break down into two groups:
- some that modify the raw and target values in parallel in order to use a cleaner in-range check of the modified values i.e. cleaner in that the rollover does not need to be considered as part of the in-range check, and the simple code above works as-is;
- some that use the raw and target range values as-is and compensate for possible rollover as part of the in-range check;
The former group handles rollover by pushing its messiness to code executed
before a simple in-range check; the latter group handles rollover messiness
as part of a more complex in-range check; all should work equally well, and "better" is in the eye the beholder, I suppose.
If implemented properly, and assuming OP's claim that the shaft, encoder, chain, product pushers, etc., are indeed all in perfect synchrony, then any of the proposed methods should work without drift.
Since the OP says they
are experiencing drift, something is not as assumed i.e. the model as implemented is wrong. There are two causes of drift that I can think of offhand:
- The code resets the HSC phase with respect to the shaft encoder e.g. as a response to the Z pulse.
- The OP has the wrong number of counts per rollover. The original post used 100; later it was 1000, presumably from a different encoder; what if it's actually 1024?
Anyway, this has been today's edition of "Our Story So Far."