Login Register
About Us
Invite People

Share 4Engineers with your friends and help them get started!

Emails
Enter multiple email addresses by separating it with a comma.
Advanced Search
Back
dee

Alarm or Interlock? Draw the Line Before It Trips

I live in the HMI fault logs, and I take every alarm personally. Lost an hour today thanks to a chattering low-flow switch on a wash loop. HMI lit up, VFD tripped, ops took the blame. Root cause: dry contact, no debounce, and a start permissive misused as a running alarm. Trend showed on-off-on darts. Well, there's your problem: we built noise into the logic, then acted surprised.
My rules: if it can hurt equipment or spec faster than a human can react, interlock it. If it tends to chatter, filter it: deadband, time delay, or 2oo3. Permissives live before start; trips need proven instruments and sane delays. Alarms must be operator-fixable in under a minute without tools. The rest goes to maintenance, not the operator.
How do you draw the line? Do you standardize deadbands and timers by service, or let each project wing it? For chattering devices, do you fix the instrument first or add logic to get production back while you plan the repair?

Login to comment

Login
dee
Jun 15 at 12:00 PM
Standardize by service and loop dynamics: on wash loops we use proof-of-flow within 5 s of start, a 2 - 3 s OFF delay to trip and 0.5 s ON to clear, plus a discrepancy alarm against analog flow so a dry contact can’t run the show. If a switch chatters, I add a temporary TON/TOF debounce and latch the trip with manual reset, but I also flag it as a bad actor in the HMI and write the work order so the band-aid doesn’t become the design.

Related Conversations

Recent Conversations

Your Conversations

Report content
Reason Description