For the described C-More increment/decrement setup, the practical bounded-selector workaround is to change the button set by state and clamp the internal value back into range. Do not use button visibility alone as the limit: a touch can complete before the display removes the button.
Check whether the limit must be hard or only operator-facing
First read the actual value being changed and identify what consumes it: an HMI-only selection, a PLC command, or a value that directly affects a machine process. The 2006 C-More configuration described here had no settable limits on its increment/decrement entry buttons. Treat this as a constraint to verify in the installed C-More editor/runtime, not as a statement about every current release.
If an out-of-range value could command unsafe motion, an extruder speed, or another hazardous condition, do not treat a screen-level workaround as the protective limit. Put the range check in the controller or other authoritative control layer, and validate the value there before using it. An HMI event can correct its own internal selector, but a delayed display update is not a safety interlock.
- Only a bounded operator choice: continue to the internal-selector design below.
- Process command or safety consequence: first verify the PLC-side range handling and safe response; stop commissioning the screen workaround if that protection is missing.
Read the selected value before choosing a workaround
Record the current selector value, its minimum and maximum, whether it is signed, and the remote-device variable that ultimately receives the choice. The example below uses a signed 16-bit internal word with four states, numbered 1 through 4. Those values are an example from the described arrangement, not universal C-More limits.
| Observed behavior | Likely design issue | Next check |
|---|---|---|
| The increment button disappears at the maximum, but the stored value becomes too large. | Visibility changed after the touch had already triggered the increment action. | Use an event clamp and confirm the resulting value, rather than trusting visibility. |
| A slider value changes when the operator touches away from its knob. | The slider accepts a touch at the touched position. | Use on-demand entry with a digital display for review before applying. |
| The displayed state is correct but the remote device receives a different state. | The internal selector and outbound mapping are separate values or events. | Inspect the remote tag and the event mapping for each state. |
| No state button appears, or an event repeatedly corrects the value. | The selector may be outside the designed range, or startup/event behavior is not configured as expected. | Read the internal value and check initialization and both clamp conditions. |
Reject visibility-only limits and unreviewed slider entry
A common quick fix is to hide the increment button when the value reaches its maximum and hide decrement at the minimum. This communicates an apparent boundary, but it does not make the action atomic: the operator's touch can arrive while the button is still visible, allowing one extra increment. A later visibility change does not undo that value automatically.
Do not use that method as the sole range control. Keep visibility as a usability aid if desired, but pair it with logic that corrects out-of-range values and verify the value readback after each action.
A slider has a different failure mode. Touching above or below the knob can set the value at that screen position, which is risky when the operator intends to drag only the knob. The described workaround was to select the slider's On Demand option, review the candidate value on a digital display, and press Enter to apply it. This adds a review step; it does not replace a controller-side range check where the command affects equipment.
Build the four-state selector with stacked buttons
For a four-position choice, use one internal signed 16-bit selector, such as the example's sWITCH RESULT, and make one button visible for each valid state. Stack the buttons in the same screen location so the visible state determines the label and action. Configure them as follows:
- Create the internal signed 16-bit selector and set its intended valid range to 1 through 4. Initialize it to a valid state before operators use the screen.
- Create the state-1 button. Configure its action to add 1 to the selector, its visibility condition to selector equals 1, and its label to
1. - Place the state-2 button over the same location. Make it visible only when the selector equals 2, configure it to add 1, and label it
2. - Repeat for state 3: visible only at 3, add 1, label
3. - For state 4, configure the visible button to subtract 3 and label it
4. This returns the selector from 4 to 1 on the next press.
This arrangement makes the normal sequence 1 → 2 → 3 → 4 → 1. The separate event clamp is still required: button stacking and visibility choose the operator-facing action, but do not by themselves constrain an unexpected value.
Clamp invalid selector values in both directions
In the Event Manager, create one event that monitors the internal selector and sets it to 1 whenever it is less than 1. Create a second event that sets it to 1 whenever it is greater than 4. These are recovery rules for values outside the valid interval; they do not replace the button actions.
Check the comparison boundaries carefully: values 1 and 4 are valid and must not trigger correction. Test values below 1 and above 4 in a controlled screen test, then read back the selector to confirm that each correction sets it to 1. Also test an invalid value while no button is being touched. If the event does not run or repeatedly overwrites a valid selection, stop and inspect the event trigger, tag assignment, and initialization behavior in the installed project.
Map the internal choice to the remote-device value
Keep the HMI selector and the remote-device output conceptually separate. Create or identify the remote variable, such as the example's sWITCH RESULT OUT, and map each valid internal state to the intended remote value. The described four-state mapping advances the output one state at a time and wraps after state 4: 1 maps to 2, 2 to 3, 3 to 4, and 4 to 1.
Implement and test the four mappings explicitly. Do not infer the mapping from the display label or assume that changing the internal selector automatically updates the remote variable. Confirm the remote tag's live value for each state. If the process expects different device codes than 1 through 4, use the controller's documented mapping and validate each command before enabling normal operation.
Verify the full touch-to-device sequence before release
Test the screen with the equipment in a safe state and monitor both the internal selector and remote output. Exercise normal transitions, boundary presses, invalid values, and any slider review path used by the application.
- From each valid state, press the displayed button once and verify the next state, including the 4-to-1 wrap.
- Press and hold or tap rapidly at states 1 and 4. Confirm no out-of-range selector value persists, and verify the event clamp returns an invalid value to 1.
- Observe the button visibility and value together at each boundary. Treat any overshoot, stale label, or delayed correction as a failed test rather than relying on the screen appearance.
- For remote control, compare the internal selector with the remote output for all four mappings and confirm that each state produces the intended device value.
- For an on-demand slider, change the candidate value, inspect the digital display, then press Enter and confirm that only the reviewed value is applied. Test a touch away from the knob to confirm the operator can detect and reject an unintended candidate.
The repeat-function request is separate from limit handling. Test the installed button object and runtime to determine whether repeated activation is available and what value sequence it produces; do not make operator instructions depend on repeat behavior until that test passes.
FAQ
Why does the increment button allow a value above the maximum?
Hiding the button depends on a visibility update, while the touch action may already have occurred. Add a separate event that corrects values above the configured maximum, and verify the stored value rather than only the button display.
Why does the four-state selector use a decrement of 3 at state 4?
The example selector is 1 through 4. Subtracting 3 from 4 returns it to 1; the other three visible buttons each add 1 to advance one state.
Why does the slider change when I touch beside the knob?
The slider can select the value at the touched position instead of requiring a knob drag. Use on-demand entry and review the candidate on a digital display before pressing Enter to apply it.
Stop and keep the command disabled if the value can exceed a process limit, the remote mapping is unclear, or the clamp fails during testing. Escalate the installed-version behavior or event configuration to AutomationDirect official support before returning the control to production.