Morning all. Case packer discharge on a 1769-L33ER, parts go past an inductive prox wired into Local:2:I.Data.3 and a CTU keeps the shift count for the board in the office.
The count lands 4 to 6 percent high against the pallet tally, every shift, and it is always high, never low. I was pretty sure it was the prox double triggering so I put a new one of the same make on, and got the same numbers within about ten parts. The old one bench tests fine sat on my desk as well, which is the annoying part.
Somebody here mentioned one-shots to me when I was asking about something else entirely. Is that what I'm missing here, or is a CTU on a fast scan always going to run over like this?
What is your scan time, and is there anything at all in front of that CTU. A prox that stays made for 40ms on a 6ms scan gives you seven counts for one part and it will look exactly like this.
Scan is 5 to 7ms and no, nothing in front of it, the input went straight into the counter. Put an ONS in yesterday and ran a shift with it. Down from 6 percent to about 2, so a lot better, still not right, and I'm not sure where the rest of it is coming from.
And it isn't even day to day. Tuesday came out within about 15 on 9000 parts. Wednesday was 300 over.
That swing is never a sensor. What happens on a bad day that doesn't happen on a good one?
That is the question. If Wednesday had jams and Tuesday didn't then I reckon there's your 300, because your counter has no idea which way the belt is going. Operator clears a jam, jogs the belt back a foot or two to get at it, jogs it forward again, and every part sitting over that prox goes past it a second and sometimes a third time.
The one-shot stopped it counting the same part once a scan. It cannot stop it counting the same part twice on two separate passes, because as far as the rung is concerned those are two parts.
Wednesday had two jams on the infeed. Tuesday had none.
Put the forward run bit in series ahead of the CTU so the one-shot only ever fires while the belt is going the right way. Ours takes the drive running output and the direction bit off the PowerFlex, with a 30ms TON on it so a stop and restart mid part doesn't clip a real one.
Worth a look if you end up chasing the gap between parts too, there's a writeup on this here: https://plctr.com/counting-cartons-end-of-line-debounce-minimum-gap/
Two shifts in and it's within about 20 either way instead of 300. It was never the prox at all. The one-shot dealt with the counting every scan half of it, and the rest was jam clears, the lads jogging the belt back and forward with parts parked over the prox and every pass counting again. Rung is the prox into an ONS, a 30ms TON on the forward run bit, the TON done bit in series with it, then the CTU.
still goes one or two over when the line e-stops with a part right on the eye, but I can live with that. Thanks priya87, mattr and wandak.
Trend the count against the run bit for a week. You'll see every jog on it.