We have a rework station at the end of a door panel line. When an operator rejects a panel they press a big mushroom button, and an ESP8266 (Wemos D1 mini) counts the presses and sends the count to Hermetry every minute. We chart it per hour.
Problem: when two or three panels come in quick succession, operators tap the button fast and the count comes out low. Tallying by hand for one shift gave 47 rejects, Hermetry got 39. The ESP reads the button with digitalRead() in loop(), and loop() also does WiFi, the publish and a 50 ms delay for debounce.
Second question: I saw Hermetry Forge mentioned for manufacturing. Is that something we could use for reject counting instead of rolling our own?
Would a capacitor across the button help? That’s what I did for a doorbell project.
Cap helps with bounce, not with missed presses. If loop() is busy elsewhere for 200 ms, a 100 ms tap is gone either way.
Owen has it. The press is shorter than your loop, so polling misses it. Use an interrupt so the count happens the moment the pin falls, and do the debounce by time inside it. I’ve had pulse counters on gas meters for years done like this:
volatile uint32_t rejects = 0; // since boot
volatile uint32_t lastEdgeUs = 0;
void IRAM_ATTR onPress() {
uint32_t now = micros();
if (now - lastEdgeUs > 30000) { // ignore bounce within 30 ms
rejects++;
}
lastEdgeUs = now;
}
void setup() {
pinMode(D5, INPUT_PULLUP); // button to GND
attachInterrupt(digitalPinToInterrupt(D5), onPress, FALLING);
}Remove the delay(50) from loop(). In the publish, copy the counter with interrupts briefly off.
Hardware: on a factory floor the button cable is often metres long next to motor cables. Add a 1 kΩ series resistor and 100 nF at the ESP pin, or better, run the button at 24 V into an optocoupler. Otherwise you’ll start counting phantom rejects.
Send a cumulative counter, not “rejects this minute”: {"rejects.total": 1532}. If a message is lost, the next one still has the right total, and a chart with the increase aggregate gives you rejects per hour.
What happens to the cumulative count when the ESP reboots? It starts at 0 again.
Right. Keep it in RTC memory across resets, or send a boot counter as well and let the chart handle the drop. Simplest is RTC memory.
On Forge: there’s no doc page for it, so I can’t tell you whether it counts rejects or how you’d switch it on. What Lewis describes is what we do on our packing lines: counters as telemetry and a bar chart per hour with the increase aggregate. The supervisors look at it at shift change.
Interrupt version is on the station since Monday. Hand tally 52, Hermetry 52 on Tuesday’s shift. I’d also been publishing “rejects this minute” and resetting to zero, so two lost messages last week had silently eaten rejects; it’s rejects.total now with the counter in RTC memory. Thanks for the Forge note Keisha. Our manager had asked me to “check Forge”, I’ll pass that to our account contact, but the counter does the job today either way.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.