Radar Level Output Acceptance: 4–20 mA, HART and Modbus Tests

Output acceptance proves that the level value and its health reach the control system with the intended meaning. A radar can measure distance correctly while the PLC applies the wrong span, a digital register is decoded with the wrong byte order or an invalid measurement is treated as a real zero. The test should follow the signal from a known field condition through current or digital variables, input processing, engineering tags, HMI, historian, alarms and final actions. Normal points alone do not prove safe failure behavior.

Define the signal contract

List each required value, unit, range, direction, resolution, update time, quality and owner. Identify whether the transmitter or control system converts distance to level, percent or volume. Use one reference datum and one tank-table owner. Record the exact model, firmware and protocol document revision so variable meaning remains traceable.

Prepare known test points

Select low, middle and upper points plus values near important alarm thresholds. State the independent reference and combined tolerance. If physical levels are impractical, distinguish transmitter simulation, current injection and software forcing; each proves a different part of the chain. Predetermine acceptance limits before observing results.

Test the 4–20 mA loop

Verify polarity, supply voltage, loop resistance, barriers, isolation, shield and grounding. At each point record expected and measured current, input counts, engineering value and displayed level. Check direction, linearity and hysteresis where relevant. Test under-range, over-range, configured fault current and open circuit, and confirm that invalid current does not become a healthy process value.

Test HART variables and status

Confirm the primary variable, engineering unit, range and damping, then verify any secondary variables and device status used by the asset system. Check polling does not disturb the analog loop and that configuration write access is controlled. Record tag and device identity. HART diagnostics provide value only if the site can retrieve and interpret them during maintenance.

Test Modbus mapping

Verify physical layer, address, baud rate, parity, function code, register base, data type, word and byte order, scaling and exception behavior. Check update age and quality in the gateway or PLC. Interrupt communication and confirm stale data is identified instead of remaining apparently current. Retain the tested register-map revision with the project.

Verify alarms and logic

Test alarm pickup, reset, hysteresis, delay, priority and operator message. Follow any permissive or interlock to its final action under the approved procedure. Confirm that maintenance mode, simulation and bad quality are visible. Independent protective functions require their own proof test and should not be inferred from a successful control-output test.

Test recovery and transitions

Cycle power and restore communication, then verify startup value, initialization status, timestamp and alarm behavior. Observe a rising and falling signal at realistic rates so filtering and scan time do not create unsafe delay. Check the historian and remote displays after recovery. Remove all forces and bypasses under independent review.

Retain a signed evidence set

Record field reference, local distance and level, current or registers, PLC counts, engineering values, quality, alarms, final action and approvers. Save configuration and protocol details. Note every untested condition and accepted deviation. The evidence should allow another engineer to distinguish a future transmitter fault from loop, mapping or control-logic change.

Engineering checklist

• Define units, range, quality and conversion ownership.
• Use known points and predetermined tolerances.
• Test normal and fault current values.
• Verify HART or Modbus mapping and status.
• Prove alarms and final actions.
• Retain signed end-to-end results.

Frequently asked questions

Does a correct local display prove the output?

No. Wiring, scaling, mapping and control logic must be checked separately.

Can a software force replace a field test?

No. It proves only the downstream logic path unless combined with physical or electrical tests.

Why test stale data?

A frozen last-good value can appear credible and drive unsafe decisions if age and quality are ignored.

Related measurement solutions

80 GHz radar level meters · Industrial IoT gateways