Pressure Switch Delays: Test Both Trip and Reset Before Handover
A pressure switch can operate at the correct pressure during a slow check yet respond too late during a short event. Checking the switching pressure alone does not establish how quickly an alarm appears or clears. Before handover, document and test both the trip path and the reset path, using the actual settings and an approved test method.
Original conceptual illustration, not a specific product, live installation or manufacturer specification.
Key takeaways
Separate switching thresholds, delays and damping.
Define the start and finish events for the full alarm path.
Test trip and clearance under an approved controlled method.
1. Separate threshold, delay and damping
WIKA’s explanation of pressure-switch time settings distinguishes a switching delay from damping. A delay requires the switching or reset condition to persist continuously for a defined time. Damping smooths the measured signal. WIKA describes separate settings for different outputs on its equipment; availability and behaviour must be checked for the exact model being installed.
A pressure threshold defines a level. A time requirement defines how long a condition must last or how quickly an indication must be delivered. Write these as separate acceptance requirements. Otherwise, a technician may correctly demonstrate the threshold while leaving the operational timing untested.
The Intelligent Digital Pressure Switch in the ProSense catalogue is a relevant example of electronic pressure measurement with switching options. Confirm the supplied output configuration, firmware and timing functions before selection. The photograph and catalogue title do not establish that a particular variant offers independently adjustable trip and reset delays.
2. Identify the timing boundary
Ask what the receiving system needs to know and by when. The device output, PLC input, controller alarm bit and operator screen are different observation points. A measurement at one point cannot establish the elapsed time at another. State the start event and finish event in the test plan, together with the allowable interval and measurement uncertainty.
For example, distinguish pressure crossing an agreed test threshold from the switch output changing, and distinguish that output change from a controller indication. Record any input filtering, programme timers, alarm persistence and display refresh settings that the integrator identifies along the path. Do not simply add nominal timer values and call the result a measured response.
Pressure-sensor response specifications also need their test definition. WIKA’s response-time explanation notes that terms such as rise time and settling time describe different aspects of response, with specifications commonly defining a percentage interval. A fast sensor specification is therefore not evidence that a complete alarm path meets a time limit.
3. Build a trip-and-reset acceptance record
Identify the instrument and each output being assessed. Save the model, range, output logic, units, threshold and reset configuration, timing settings and receiving input assignment.
Record the intended behaviour in plain language. State whether a brief excursion should be ignored, a sustained condition should be indicated, and when clearance should be reported. Obtain the responsible engineer’s acceptance limits.
Define a controlled test arrangement with suitable pressure-reference and event-recording equipment. Check that the equipment can resolve the intended time intervals; a slowly updated display is insufficient evidence for a short-duration event.
Assess trip and reset separately. Retain time-aligned pressure evidence and output-state evidence. Include a sustained condition and approved short-duration cases around the configured delay, with enough margin to avoid ambiguous boundary results.
Compare local output timing with the receiving indication. Investigate a discrepancy at the stage where it appears, rather than changing several timers together.
Repeat the agreed cases and record restoration of the operating configuration. Save unsuccessful results and unresolved limitations alongside the successful evidence.
4. Hypothetical example: clearance matters too
Consider a non-safety monitoring demonstration whose approved specification calls for an indication after a condition persists for two seconds and clearance after one second of recovery. These numbers are illustrative, not recommended plant settings. A short excursion of half a second is intended to produce no trip, while a sustained excursion must produce one.
Testing only the sustained excursion misses two questions: whether the short event was correctly rejected and whether recovery produces clearance within the agreed time. The test record should show the applied condition, its duration, the resulting output state and the receiving indication for all three cases. Repeat an interrupted condition to check the documented timer behaviour rather than assuming it accumulates separate excursions.
Original explanatory diagram. Numerical values are hypothetical where shown; follow the actual equipment documentation and approved application method.
5. Keep the test within its authorised scope
Do not increase a delay merely to hide nuisance alarms. Determine whether the fluctuation is acceptable process behaviour, a measurement problem or a condition that requires action. Do not assume that smoothing a display changes a switching output, or that testing one output proves the other. Record any model limitation instead of describing an unsupported setting as available.
This is an educational acceptance framework, not a live pressure-test procedure. Application-specific pressure generation, isolation, electrical work and validation require competent people and approved methods. Do not bypass plant interlocks or operate machinery to create a test event. A generic electronic pressure switch is not established as a certified safety function by passing these checks.
For the next technical discussion, provide the supplied model, manual, saved settings, required trip and clearance behaviour, receiving controller details and the observations already collected. That gives ProSense a concrete basis for checking the instrument and integration requirements.
6. Technical sources
Need help with your application?
ProSense Instruments - discuss instruments and output options: sales@prosenseinstruments.com.au or 1800 560 854.
ProSense Solutions - discuss system requirements: sales@prosense.com.au. ProSight Software - discuss software requirements: info@prosightsoftware.com. Device integration must be confirmed for your application.
Comments