Can DirectTouch ENT Trigger an Immediate PLC Update?

On a DirectTouch ten-key keypad, configure the ENT key to set a PLC bit and use that bit to trigger the math; detecting a register change alone does not prove that the operator pressed ENT.

Check whether ENT can set a PLC bit

First inspect the keypad configuration for an action that writes or triggers a PLC bit when the operator presses ENT. The DirectTouch keypad capability described for this application is to trigger a PLC bit, with C0 given as an example. The configuration screen, available actions, and exact setup steps can vary by panel and Screen Creator version, so use the installed software and panel documentation to locate the setting rather than guessing at a menu path.

1. Identify the keypad object used by the adjustment screen and the PLC register receiving its entered value.
2. Find the ENT key action and determine whether it can trigger a PLC bit.
3. If available, select a bit reserved for this function and monitor it online while pressing ENT once.
4. Confirm whether the bit is momentary, latched, or held until another action. Configure the PLC logic to match the actual behavior.

If the bit changes only on the intended key press, use it as the commit event for the calculation. If the panel cannot produce that event, proceed to the data-change fallback below. A PLC bit tied to ENT is the direct signal; a changed register is only an indirect clue.

Read the target value and test what the keypad writes

Before changing logic, monitor one adjustment variable while entering a value. Record the value before editing, the value while the operator is entering it, and the value after pressing ENT. This establishes whether the keypad writes continuously during entry or commits only when the key is pressed. It also shows whether pressing ENT with the existing value produces any change at all.

The distinction matters because the application has approximately 20 variables that operators update at separate times. A single generic “some register changed” condition can run the wrong calculation if another value changes, while a comparison cannot recognize an Enter press that leaves the register unchanged. Map each keypad field to its target and its associated calculation before applying a shared trigger.

Do not treat every value change as an Enter press

A common quick fix is to compare a live register with a saved copy and fire a one-shot when the values differ. That can detect a new value, but it cannot distinguish a keypad commit from another write to the same register. It also misses an Enter press that resubmits the current value. With multiple independently edited variables, a detector that watches the wrong address can trigger a calculation for the wrong field.

The historical ladder sketch uses V2000 as the existing value, V2001 as the comparison value, and C1 as a one-shot when the two values differ. It then uses C1 to run math on V3000. Treat those addresses and instructions as an example, not as universal DirectTouch addresses or a verified program for a particular PLC.

There is a sequencing trap in the sketch: it shows copying V2000 to V2001 before comparing them. In a scan-ordered program, that copy can make the values equal before the comparison, suppressing the change pulse. Compare the new value with the stored previous value first; generate the one-shot; then update the saved value after the comparison has consumed the old value. Confirm the actual instruction execution and one-shot behavior in the PLC programming environment.

Use the Enter bit to trigger only the intended calculation

When the panel provides an Enter bit, keep the event path explicit. Associate the active keypad field with its target value and calculation, then trigger that calculation from the bit. For a screen with many adjustment fields, either dedicate a bit per action or use an existing selection/field-identification mechanism to decide which calculation belongs to the Enter event. Do not assume that one Enter bit identifies which of 20 values the operator edited unless the PLC logic already tracks the selected field.

1. Reserve the bit used by the panel and confirm no unrelated logic writes to it.
2. On the PLC side, detect the bit’s active transition or active state according to its observed behavior. Create a single calculation event rather than allowing a held bit to repeat the operation every scan.
3. At that event, calculate using the committed target value and write results only to the intended destinations.
4. Clear or re-arm the event using the method compatible with the panel’s observed bit behavior.

The math sketch names ADD, SUB, MUL, and DIV as example operations on V3000; it does not define the required formula or destination for this application. Insert the actual calculation and check its operand and result registers. If division or other constrained arithmetic is involved, handle invalid inputs in the application logic rather than relying on the keypad event to make the math safe.

Keep the adjustment window from burdening every scan

The reported production concern was not just operator workflow: the earlier arrangement entered a different part of the program while the adjustment window was active, and scan time increased enough to upset program behavior. Recreating that arrangement while adding an Enter trigger can preserve the same problem. Keep the adjustment path focused on the selected value and the calculation that must run after commit instead of repeatedly processing all adjustment work while the screen is open.

Measure the controller’s scan time before and during the adjustment window, then compare it while the new trigger logic runs. Use the controller’s own scan-time display or diagnostic data; do not assume that reducing the visible ladder rungs or adding a one-shot automatically makes the program fast enough. Check the worst observed condition with the normal control tasks active. If scan time still affects machine behavior, stop expanding the adjustment logic and review task execution and program structure with the controls owner.

Use change detection only when the panel cannot signal Enter

If no direct Enter action is available, a previous-value comparison can be a fallback when a changed value is an acceptable proxy for commit. Make the comparison specific to each target or to a carefully selected active target; then pulse the calculation once and refresh the stored comparison value after detecting the change. For independent variables, maintain the matching previous value for each target rather than comparing unrelated values against one shared snapshot.

Test the fallback against three cases: a genuinely changed value, an Enter press that submits the same value, and a write that changes the register without an Enter press. The fallback should fire only for the cases your process intends to treat as an update. If the required behavior is “calculate on every Enter, including a same-value submission,” a value-change detector cannot meet the requirement; return to the panel configuration question or use a separate commit signal.

Verify the update without reopening the scan-time problem

Test first with the machine in a state where the calculation and its effects can be observed safely. Monitor the panel’s target value, the Enter bit if used, the one-shot/event, the math result, and scan time. Verify both a changed entry and a same-value entry, then verify another adjustment variable to confirm that one field does not trigger another field’s calculation.

1. Enter a changed value and press ENT; confirm the target, trigger event, and expected math result in sequence.
2. Repeat with the same value; confirm the observed behavior matches the required operator workflow.
3. Change a different adjustment variable and confirm only its associated calculation runs.
4. Leave the adjustment screen and confirm the event does not retrigger or continue processing.
5. Compare scan-time readings with the original adjustment-window behavior and verify normal control remains stable.

Do not release the change based only on the keypad appearing to accept the value. The PLC result and machine behavior must agree, and the adjustment-window scan time must remain within the operating limits already established for the application.

FAQ