1. Doesn't a longer stride length imply a slower base RPM, assuming a constant MPH? If yes, then a longer stride should be easier for the PLC to handle (longer time between encoder transitions). So the result that longer stride length generates spikes seems odd. How are you calculating the pulsePeriod? I.e. what are you using for a clock to measure the time between encoder edges? What is the resolution of that clock (how many bits; how much time is represented by each tick)? Does that clock "roll over" i.e. reach its largest possible value (all bits are 1) and then increment to 0 on the next tick?
2. For the eight triggers per cycle used now, I assume you are calculating the pulsePeriod between each successive pair of rising edges. For sixteen triggers, you would need to calculate the pulsePeriod between each rising/falling and falling/rising pair of edges.
2.1. In the current code, at each rising edge, you subtract the absolute clock time of the previous rising edge from the current absolute clock time, call the current pulsePeriod, and put it into the FIFO, so the FIFO looks like this:
- pulsePeriod from 8th previous edge to 7th previous edge
- pulsePeriod from 7th previous edge to 6th previous edge
- pulsePeriod from 6th previous edge to 5th previous edge
- pulsePeriod from 5th previous edge to 4th previous edge
- pulsePeriod from 4th previous edge to 3rd previous edge
- pulsePeriod from 3rd previous edge to 2nd previous edge
- pulsePeriod from 2nd previous edge to 1st previous edge
- pulsePeriod from 1st previous edge to current edge
Of course, those values shift at each edge because you are using a circular array as a FIFO, but that does not change anything.
You then sum those eight elements' values to get the total period from the 8th previous edge to the current edge i.e. 1 cycle period. Finally you save the current absolute clock time as the previous absolute clock time so you can calculate the next pulsePeriod at the next edge which will occur in a couple hundred milliseconds or so.
What I am suggesting is that, instead of calculating each individual encoder pulsePeriods and summing them to get cycle period, you could instead store the absolute clock values at each edge into the FIFO, so the FIFO would look like this:
- absolute clock time from 8th previous edge
- absolute clock time from 7th previous edge
- absolute clock time from 6th previous edge
- absolute clock time from 5th previous edge
- absolute clock time from 4th previous edge
- absolute clock time from 3rd previous edge
- absolute clock time from 2nd previous edge
- absolute clock time from 1st previous edge
Then, to get the current edge's cycle period, you can do one subtraction, i.e. subtract the absolute clock current absolute clock time from the 8th previous edge from the current absolute clock time. Finally you overwrite the array location with the absolute clock time from the 8th previous edge with the current absolute clock time, and then wait for the next edge.
The FIFO array encodes the same information, albeit in a different way, that requires fewer calculations and allows for simpler code.
3. To adapt your current ST code, make it the code that is called by the interrupt. I would change the code to save two absolute clock times outside the FIFO array: the current time of the latest interrupt; the time of the 8th previous interrupt to that which was overwritten by the latest time. You would also need to update the circular pointer into the FIFO. The details will be specific to your current brand and model of PLC. You will no longer need to detect edges in software to trigger the execution of the ST code as the interrupt handler will take care of that.
