A current clamp reads a motor’s power draw. Plenty of machines already have a cleaner signal sitting right there for the taking: a stack light’s own run/stop segments, a door interlock, a cycle-complete relay, a limit switch. Each of those is a dry or wet contact, and a dry or wet contact wires straight into the gateway’s isolated digital inputs. No clamp, no threshold to calibrate, just a clean on or off. This guide covers wiring one in, keeping a noisy contact from lying to you, and what a bare on/off signal can and can’t tell you.
Dry contact versus wet contact
The gateway’s panel breaks out two isolated digital input channels, each with its own +/- terminal pair, and it supports two wiring styles depending on what’s on the other end. A dry contact is passive: a plain switch or relay contact with no power source of its own, a limit switch, a stack light’s own internal relay output, a simple mechanical interlock. Wire it straight across the DI’s +/- pair. The gateway supplies the small sensing current itself. A wet contact is active: a powered sensor like a PNP or NPN proximity switch that outputs its own signal. Wire its output to the DI’s + terminal and its return to -, using either your own supply or the panel’s own 12V output terminal if the sensor draws little current.
Getting this backwards doesn’t damage anything. The inputs are isolated. But it does mean nothing reads. If a fresh DI tag sits stuck at one value no matter what the switch does, check which style you wired first, before assuming the signal itself is bad.
A quick bench check before wiring anything real: short the DI’s + and - terminals together with a jumper and confirm the tag flips in Spall. That single test proves the input channel, the tag, and the gateway’s own polling are all working, before a real switch, a hundred feet of cable, and a locked electrical panel are in the way of finding out the same thing the hard way.
Debouncing, or why a clean switch can still look noisy
A mechanical contact doesn’t transition cleanly from open to closed. The contacts physically bounce against each other for a few milliseconds on every actuation, and without correction that bounce shows up as several rapid on/off flickers instead of one clean edge. Left uncorrected, one real switch closure can register as three or four counted events. That’s a real problem for anything counting transitions: a cycle-complete relay feeding a part count, a door interlock feeding an open/close count.
Spall’s digital input reads with debouncing built into the read itself, at the driver level: a configurable window, 10 milliseconds by default, that the signal has to hold steady before a transition counts as real. A dry contact’s own mechanical bounce is shorter than that window in most cases, so the default handles it without any tuning. You can also choose which edge counts, rising only, falling only, or both, matched to how the specific contact behaves. A normally-open relay that closes briefly on each cycle wants a different edge setting than a door switch that should register both the open and the close.
What you can infer from an on/off signal
A dry contact tells you one thing: open or closed, right now. Everything past that is interpretation, and some interpretations hold up better than others. A run/stop relay wired to a machine’s own control circuit is a reliable run signal: the machine’s own logic decides when that contact closes, the same trustworthiness as reading a PLC’s run bit directly. A door interlock or a stack light’s red segment tells you the machine stopped, but not why. A jam, an operator-initiated stop, and a changeover all close the same contact. A bare digital input has no way to tell them apart. A reason code, entered by a person, is what fills that gap.
A stack light’s segments deserve their own note. Its green segment is usually a reliable proxy for running, and its red segment for stopped, if the light is wired to the machine’s own control logic rather than to something an operator can flip independently. An amber segment is often ambiguous by design: some machines use it for a warning state that isn’t quite down and isn’t quite running. A light with more than a simple two-color scheme is worth confirming with whoever built the panel before assuming a segment means what it looks like it should mean.
That confirmation is worth doing before wiring, not after. Ask two questions: what drives each segment (the machine’s own PLC logic, or a switch an operator or a supervisor can trigger by hand), and does any segment double up for more than one condition. A light with a flashing red distinct from a solid red is common on some machines, one meaning a fault and the other a normal end-of-cycle stop, and a digital input reading plain on/off can’t tell a flashing state from a solid one unless you wire a separate contact for it. Get the answer from the panel builder’s documentation or a quick conversation, not from watching the light for a few minutes and guessing.
What it doesn’t give you
A bare digital input carries no alarm text and no program name. It’s a single bit, and a single bit is all it will ever be. If a cycle-complete relay exists, it can drive a real part count the way a native counter would, covered in its own guide, but a run/stop contact alone tells you nothing about how many parts moved while it was closed. Know which specific signal you’ve wired, and don’t expect a contact to answer a question it was never wired to answer.
This is also a case where upgrading later costs nothing. A machine wired for a dry-contact run signal today keeps every hour of history it already collected if a controller connection replaces it down the line. Only the source changes going forward. Starting with a stack light or an interlock isn’t a placeholder measured against some more complete setup. It’s a legitimate first step on its own, and the record it builds stays valid either way.
Quick recap
- A dry contact wires straight across the DI’s plus/minus pair. The gateway supplies its own sensing current
- A wet contact, a powered sensor, wires its output into plus, with its own supply or the panel’s 12V output
- Debouncing happens at the driver level, a 10ms default window that filters out a mechanical contact’s own bounce before it’s counted as a transition
- Choose rising, falling, or both edges to match how the specific contact behaves
- A run/stop contact tied to the machine’s own control logic is a reliable state signal. A bare on/off can’t tell you why it changed
- A stack light’s amber segment is often ambiguous by design. Confirm what each color means before trusting it as a state