When a membrane key is used for repeated adjustment while held, define the delay before the first repeat separately from the interval between later repeats. Also record how event generation and processing stop after release. A passive switch provides an open or closed input; the host implements repetition. A continuously closed contact does not mean the user has pressed the key several times. Timing, step size and stopping criteria are project-specific. This article covers ordinary, non-safety menu or settings operations, not motion control, emergency stops or enabling functions.
In its PC300-12/PC300i-12 announcement dated October 30, 2026, Komatsu describes an 8-inch touchscreen monitor positioned near the operator, with sales planned from November that year. This is a recent equipment-interface update, not evidence that planned sales or deliveries have already occurred. The announcement does not identify membrane keys, repeat behavior, a software framework or supply by Baoshengda Technology.
If your own equipment also updates an operator-side terminal and retains membrane keys for menu navigation or ordinary setting adjustments, specify what a tap and a sustained hold each do. How long the user waits before repetition begins, and how quickly changes follow, affect the assessment of that operation. These are behaviors to define for your project, not an inference about the machine in the announcement.
Measure two timing quantities, not one “long-press time”
Record the initial wait and the later repeat interval separately in the timing table. One “long-press time” field cannot stand for both. The first determines when repetition begins after a confirmed press; the second determines how soon another event is generated once repetition has started. State whether the initial press performs one step immediately. If it does, count that initial action separately from the first repeat.
The Qt QAbstractButton documentation defines the initial repeat delay and repeat interval as separate properties, autoRepeatDelay and autoRepeatInterval. This illustrates two independent timing settings for that software button, not universal membrane-key parameters. This article does not adopt all of that class's signal semantics or imply that your equipment uses Qt.
The following is a suggested timing record. First define the confirmed-press point, time base and initial-action policy, then enter expected and observed results. The table supplies no universal millisecond values. Input confirmation, event generation and interface processing need aligned records; a screen recording alone cannot establish the underlying timestamps.
| Observation phase | What to record | Rule to check against |
|---|---|---|
| Confirmed press | The input start point for this hold; whether one initial action has already been generated | Action on press or after another condition; count any initial action separately |
| Wait for the first repeat | Time from the agreed start point to generation of the first repeat event | Initial delay and treatment of release exactly at the boundary |
| Continued repetition | Generation times of adjacent repeat events and their corresponding processing records | Repeat interval; for stepped acceleration, the applicable stage and transition conditions |
| Confirmed release | Release-confirmation time, the last newly generated event and items still awaiting processing | When new repeats stop; whether pending items are canceled or processed and the allowed delay |
| A limit is reached or the page is left | The current target, limit value or page state, and the destination of later events | Stop, hold or another approved behavior; do not assume a transfer to a new target |
Does repetition come from software or changing contacts?
The LVGL 9.3 input-event documentation lists a long-press event separately from a repeated long-press event. Repeats follow its configured long-press and repeat times, with conditions such as no scrolling. This is a software component's event model. A repeat event does not by itself mean that a physical contact has closed again, and those conditions must not be applied to every host.
For one operation, retain the contact or input state, the confirmed held state, repeat-event generation records and interface-processing records. If the held input is stable and software repeats according to the approved policy, continuous changes on screen alone do not establish a faulty switch. If repetition is not configured but several actions occur, continue checking event origins and processing paths. If the input itself changes, examine the contacts, connections or input circuit using actual evidence; do not assign responsibility from the symptom alone.
Repeated adjustment in this article is intentionally permitted by the project. Do not substitute an arbitration table that allows only one action for a sustained hold. For a key that performs a short-press or long-press action once, see short/long-press arbitration (Chinese). For abnormal input transitions, see press and release debounce checks (Chinese). A repeat interval and a debounce time are also different settings.
Identify what stops after release or at a limit
“Stop on release” must specify whether it stops new event generation or adjustment actions not yet executed. No new events after confirmed release, with previously queued events still changing the interface, is different from generating new repeats after release. Check the cancellation or execution of pending items and the allowed delay against the project rule. Preserve records of actions already executed; clearing a log must not make them appear never to have happened.
For the operator-side terminal in the conditional project scenario above, an approved simulation or isolated setup can cover a tap followed by release, release during the initial wait, release during repetition, and a continued hold at the end of a list, a value limit or a page exit. Record the actual target and where every event goes. If the project prohibits an existing held input from controlling a new page, check that confirmed rule. The old page merely ceasing to refresh is not enough. These are not test results for the equipment in the announcement.
The equipment owner must set timing boundaries, repeat rate, maximum adjustment range, recovery conditions and test counts for the operating task. Do not shorten the interval arbitrarily to make the interface feel faster. Stopping an ordinary menu operation on release does not verify a mechanical stop or a safety function. Do not trial changes to repeat logic or bypass interlocks on running equipment.
Keep repeat behavior in host-system records
Shenzhen Baoshengda Technology Co., Ltd.'s Chinese membrane-switch customization information requests key definitions and circuit or interface information, with mapping, continuity and assembled operation checked against matching housing and board versions. These records can identify which key and circuit provide the input; the equipment software owner confirms repeat events and processing policies. The public page does not establish a service for arbitrary repeat firmware, interface boards or complete equipment-software verification. The English product page provides localized product information.
When using the project contact route, provide key and pin assignments, sample and drawing versions, and press/release records on the component side. On the host side, include the software version, initial action, first-repeat delay, repeat interval, stopping and boundary policies, and the layers already checked or still under investigation. A graphic overlay or keypad overlay alone is not a complete membrane switch. For a metal-dome overlay used with a customer's PCB, list that PCB and the readout circuit separately.
The cover shows only an instrument panel's display window, up/down arrows, function legends and tail. It does not establish repeat functionality, an interface protocol or completed timing tests. Base the handoff conclusion on your project's input and event records, not on a photograph or the fact that holding a key makes a display change.