Mod-12 carton counter with an asynchronous clear
A box-filling line packs 12 items per carton. The counter is two cascaded 74HC161 synchronous counters clocked directly by a photoelectric sensor at up to 300 items per minute. The board clears the pair by decoding the low nibble 1100 with a 4-input NAND whose output drives the asynchronous /MR pin of both chips. A 'carton full' lamp is driven from a 74HC74 whose clock is the same decode line. Since installation, roughly one carton in ten thousand contains 13 items, and the lamp occasionally flashes at the wrong instant. Separately, a reset pushbutton on a 2 m cable adds two counts each time it is pressed, and the sensor input behaves the same way when its cable is routed alongside the motor drive. There is plenty of time between items for the counter to settle. The deck may not be modified outside the counter board, and the PLC program, which only reads the totalised count, must stay untouched.
1. Explain the mechanism that produces a 13-item carton and the spurious lamp flash. Why is the decoded state 12 itself not the whole story?
Read the worked answer
When the count reaches 12 the low nibble is 1100, the NAND output falls and /MR of both '161s is asserted. The clear is asynchronous: it acts within about two gate delays (~15–25 ns) of the decode, not on a clock edge, so state 12 genuinely appears on Q3–Q0 for that window - and the 74HC74 lamp latch is clocked by the same decode line, so it can capture '12'. That is the wrong flash.
The 13th item comes from the release of the clear. /MR rises again as soon as the outputs leave 12, and the release delay depends on each package's internal reset path. The two chips do not leave reset at the same instant. If the release lands near a sensor edge, one chip can accept that edge while the other is still held, so the pair restarts from a value other than 0000 0000 - say 0x03 or 0x04 - and needs 13 items, not 12, to reach the next decode. A narrow noise spike on the decode line produces the same effect. The decoded state being visible is only part of the fault; the asynchronous release is the part that loses the count.
2. Redesign the mod-12 function so that it is immune to decode glitches and to reset-release races. State the state you decode, why the design is safe, and give the reload value if a parallel-load device is used instead.
Read the worked answer
Replace both '161s with 74HC163 devices, whose clear (/CLR) is synchronous. Decode the low nibble 1011 (count 11) and feed that decode to /CLR. The clear is sampled by the clock: on the edge following the decode the counter goes to 0000, so state 12 never exists on the outputs and the lamp latch can never capture it. Because /CLR is only examined at the clock edge, a 20 ns glitch on the decode line that is not present at the edge has no effect. The decode is valid for a full 200 ms item period, which is the key difference from the asynchronous version.
Parallel-load alternative: use /PE and decode terminal count 255 (RCO of the low chip enabling the high chip). Load the pair with 256 − 12 = 244 = 0xF4, and the sequence 0xF4 … 0xFF gives exactly 12 states. Again the decode of 255 is stable for a whole clock period, so no race and no glitch sensitivity.
Both variants keep the same 4-bit decode logic and the same pin count, so the counter board can absorb the change. Whichever is used, the lamp should be driven from a state that is unambiguous (e.g. count 11) rather than from the clear pulse itself.
3. The reset button adds two counts per press and the sensor input misbehaves near the motor drive. Select and justify a debounce and filtering scheme, giving component values and showing the timing calculation.
Read the worked answer
Both faults are the same problem - fast edges arriving at a CMOS input - so both need a Schmitt trigger plus an RC.
Debounce: 10 kΩ to VCC and 1 µF to ground at the 74HC14 input, giving τ = 10 ms. With VT+ ≈ 2.9 V and VT− ≈ 1.7 V at 4.5 V, the rise time to VT+ is τ·ln(5/2.9) ≈ 5.4 ms and the fall to VT− is τ·ln(5/1.7) ≈ 10.8 ms. Both comfortably exceed a 2 ms contact bounce, and a deliberate press by a human (tens of ms) is still passed. The Schmitt is not optional: an RC-driven slow edge on a plain CMOS gate causes both inputs to conduct simultaneously, drawing extra current and oscillating.
Cable noise: add a second 1 kΩ/100 nF RC at the receiving end of the sensor line (τ = 0.1 ms, fast enough for 300 items/min), keep the pair twisted, and route it away from the motor cable. If the environment stays hostile, replace the voltage input with an opto-isolated or current-loop input; an RC alone will eventually fail when the coupling is capacitive and common-mode.
Cheaper software debounce is not available here: the counter is hardware and the PLC program is frozen.