If a membrane key is already held when power is applied, contact continuity alone does not establish whether the first command is correct. The equipment project must define whether an input held through startup may generate a command, when new operations become eligible for acceptance, and how a release followed by a fresh press is recognized. Check the contact state, program input state, and command events on one timeline. This article covers ordinary, non-safety operating keys and does not prescribe a startup rule for every controller.
On 21 October 2026, the Dongfeng procurement platform published an AGV unmanned-forklift procurement candidate notice (Chinese). It names the buyer as Dongfeng Auto Parts (Group) Co., Ltd., General Casting and Forging Branch (东风汽车零部件（集团）有限公司通用铸锻分公司). The notice records completion of evaluation on 20 October and a public-notice period of 21 to 22 October. This was recent procurement information checked while preparing this article on 23 October, not an event that happened that day or a final award announcement.
As automation equipment moves through procurement evaluation and delivery preparation, equipment teams can include startup conditions for operator inputs in their own acceptance scope. If their equipment has separate membrane keys, one question is whether a key already held when initialization finishes counts as a new operation. The notice does not disclose the AGV's key construction, startup logic, or faults, and it does not establish any Baoshengda supply relationship. The checks below concern the reader's own project.
A closed contact and a new operation are different observations
While an ordinary key remains held, its electrical input may remain in one state. Whether the application generates an operation request depends on the project's acceptance rules. An active input does not by itself establish that a command was issued, or that the equipment executed it. Keep these observations separate in the test record.
Beckhoff's TwinCAT 3 R_TRIG documentation describes rising-edge detection: Q is true for one cycle at a rising edge of CLK, and another such output requires a subsequent falling edge and rising edge. A sustained input state and a brief event are therefore different objects. That page does not fully define every startup, reset, or retained-variable case. It cannot establish that a particular machine will, or will not, trigger at power-up.
Rockwell's FactoryTalk Design Studio ONS documentation separately describes prescan behavior: the instruction sets its internal storage bit true to prevent an invalid first-scan trigger. This is a specific instruction behavior, not a function of the membrane switch itself. It cannot be applied directly to another PLC, microcontroller, or equipment program. The responsible engineer still needs to review the actual instruction, initialization, and application acceptance path.
Identify the startup moments that the test must reproduce
The sequence table below is a project verification aid, not a test result for the reported AGV or a universal acceptance criterion. Perform checks only in an approved simulation, isolated bench setup, or controlled test environment. The equipment owner must separately plan tests involving moving machinery, powered interfaces, or safety circuits. Do not create test conditions by casually restarting operating equipment, shorting terminals, or bypassing interlocks.
| Test path | Moments to distinguish | What to check |
|---|---|---|
| Start with no key held, then press after the ready state | Initial input state, readiness, fresh press | Record acceptance of the first operation against the approved rule; use this as a comparison path |
| Hold the key before startup and beyond readiness | First input read, end of initialization, opening of acceptance | Define in advance whether the held input generates a request; contact closure alone does not decide this |
| Press during initialization and hold across the opening of acceptance | Whether the press occurs before or after acceptance opens | Check whether an earlier operation is issued when acceptance opens, and whether this matches the project rule |
| Keep the key held during a program restart, where applicable | Program restart, state initialization, renewed acceptance | Record this separately from a cold power-up; the program owner must confirm applicable retained states |
| Release after readiness, then press again | Recognized release, fresh press, command request and acceptance | Check when the next operation becomes eligible; count continued holding separately from a fresh press after release |
The opening of acceptance needs an identifiable reference, such as a project-defined ready state or logged event. An illuminated screen may not establish when the program starts accepting operations. Define expected outputs, prohibited outputs, end states, and acceptable record precision for each row before testing. Leave an undefined row open for confirmation; do not rewrite expectations afterward to make the observed behavior a pass.
Find the first difference on the same timeline
Follow the records through the contacts, program state, and command events to find the first departure from the expected sequence. First identify the sample, key and pin mapping, panel and main-board revisions, software revision, and whether this run is a cold power-up or a program restart. Then use the project's approved measurements and logging to relate contact or input observations, program recognition, the opening of acceptance, command requests, and acceptance results.
For example, if the contact stays closed but the program log shows a new request when acceptance opens, first review state initialization, event generation, and application acceptance rules. That record alone is not a reason to diagnose key bounce. If the input observation itself changes, separately investigate contact behavior, connections, and input processing. This hypothetical example does not report a fault at any manufacturer. If a layer of evidence is missing, the cause remains insufficiently supported.
The project must agree on repetitions, time resolution, starting states, and pass criteria. State which revision and path the acceptance conclusion covers. A successful press-and-release test during normal operation may leave startup holding and program restart untested. Safety functions and permission for motion after abnormal recovery are outside this ordinary-key verification scope.
Confirm the interface and the equipment's startup rules separately
Shenzhen Baoshengda Technology Co., Ltd.'s membrane-switch project information (Chinese) asks for key definitions and circuit or interface information, with mapping, continuity, and installed fit checked using the same enclosure and main-board revision. The English membrane-switch page also provides project-input guidance. Relate the key-to-input mapping to the startup timeline confirmed by the equipment owner. The agreed supply scope determines component and assembly checks; the relevant equipment team must confirm program initialization, command acceptance, and system verification. The public product information does not establish that Baoshengda supplies PLC programming or equipment startup acceptance services.
A separate graphic overlay or key overlay without a switch circuit is not a complete membrane switch. For an overlay with metal domes that works with the customer's PCB, identify that PCB and the assembly conditions. The cover shows an existing sample with a window, key legends, and a flexible tail. It is not the reported AGV and does not prove that a startup test has passed.
For extra inputs during pressing or release, see membrane-switch debounce acceptance (Chinese). If the same key also distinguishes short and long presses, see short- and long-press rules and verification (Chinese). Neither replaces checks of the initial startup state and the opening of acceptance.
When discussing a membrane-key interface through the project contact page, provide the current key and pin mapping and assembly revisions, and mark input states still unresolved on the startup timeline. Ask the equipment owner to define the expected first operation, then check the same revision. Keep untested startup paths listed as outstanding.