Ken,
I get the impression that borbob might be running the logs under an encoder equipped wheel. I suspect he uses the photo-eye to initiate and cease counting. When the log runs out from under the wheel the wheel and encoder continue spinning. If the eye is off then the encoder-counts don't count... as it were.
It actually is a reasonable way to do it, but, only if the wheel can be counted on to provide positive traction for the entire length of the log.
The problem is in how to develop positive traction for the entire length of the log. When the log first encounters the wheel, depending on the speed of the log, sometimes the wheel does a bounce & spin. The number of counts that occur during the bounce & spin is sometimes not so consistent. Sometimes the log enters the measuring area quickly (more bounce) and sometimes it enters slower (less bounce). So you can't "assume" any particular "bounce-count-value".
The scheme shown below works better.
___
/ \ <---- Wheel
+-------------------------+ \___/
| Big Honkin' Log |
| -------->>> |
+-------------------------+
+-+ +-+
| | | |
| | | |
+-+ +-+
1 2
Sensors
|<-- X.X" -->|
.
The mistake that a lot of programmers make is in not accepting that sometimes things are not as "positive" as we would like. They would use a single eye aligned with the wheel (Sensor #1 shown above).
When the eye goes on they begin counting encoder pulses. Then, when the eye goes off they stop counting and calculate the length.
However, as I mentioned, there is that damned variation in the bounce & spin.
The better way to do it is to accept that there might be a bounce & spin. Depending on the speed of the logs, there might not be any bounce at all. However, in this day and age of hurry-up, you can bet that the log will be moving as quickly as it can.
Often, length measurements are performed in open areas where there is not a means to impose a positive drive-force to the log's speed. The log simply moves as fast as it can... sometimes fast... sometimes slower. Snags happen.
Because of this, the speed of the log can not be expected to be consistent (unless there is a means of providing a positive drive-force in that area).
So... you either fight it, or you accept that there might be an unexpected bounce... or not.
In the figure above there are two photo-eyes; #1 and #2. The smart programmer won't start counting pulses until eye #2 goes on. He would then continue counting pulses until eye #1 goes off.
Since the distance from Eye #1 to Eye #2 is known (X.X"), it is simply a matter of adding the appropriate number of pulse counts to the total before performing the length calculation. Alternatively, you could calculate the length based on the total pulses counted and then simply add the distance between sensors to the calculated length.
The idea is to give the wheel a chance to bounce, spin, and then settle down into positive traction before beginning the count accumulation.
Whether or not borbob needs to use a high speed counter depends on the greatest number of pulses per second that might occur (which depends on the size of the wheel as well as the speed of the log) and the scan-time of the PLC.
Depending on his particular requirements for accuracy, he might be able to up-size the wheel so as to reduce the number of pulses per second.
BTW, it is better to use a "spiked-tooth-wheel" rather than a "rubber-roller-wheel"... the traction is much more positive. A "spiked-tooth-wheel" will overcome a failing bearing much better than than a "rubber-roller-wheel" will. But, of course, that failing bearing will have to be replaced eventually.
(120)