The proposed payment lockout combines a PLC date check, a persistent paid/unlocked state, and an EZ-series panel screen for code entry; the panel model and PLC memory behavior must be confirmed before wiring that logic into a machine.
Confirm the panel and PLC before using the suggested addresses
The request names an EZ-SP, while the programming suggestion describes EZ-TP panel software and its PLC-to-panel variable. Treat that mismatch as the first decision point: a screen-selection method or numeric-entry control from one panel model may not apply to another. Identify the panel model, PLC CPU, programming software, memory map, and the actual variable used for panel communications from the installed hardware and its manuals.
| Check | Reading or evidence | Next decision |
|---|---|---|
| Panel identity | Model label and supported software/control objects | Use the correct documented screen and numeric-entry configuration. |
| PLC identity | CPU model and memory map | Confirm clock registers, retentive ranges, and nonvolatile-memory instructions. |
| Current panel interface | Configured PLC-to-panel variable and existing screen-change test | Use that interface rather than copying an assumed address. |
The legacy suggestion uses V2000 as an example panel screen variable, and mentions C1000 and above for a retentive bit on a 250-1. Those are examples from one setup, not universal addresses. The same comment guesses the PLC clock values as V7767 through V7764 and explicitly says to double-check them. Read the CPU memory map and clock configuration instead of deploying that guess.
Read the trigger value and choose a calendar or runtime limit
Decide whether the machine needs a one-time shutdown on a calendar date or a purchased-hours limit. The date-based proposal sets the PLC clock and compares its day and month with the cutoff. That comparison needs a defined policy for the year, clock setting, and what happens after a clock reset; a day/month comparison alone can recur each year. Read the clock registers live and verify the configured comparison before testing the stop condition.
An alternative described for rentals accumulates allowed operating hours. An unlock code adds a purchased quantity of hours, and that code is disabled after use. The design also includes a machine-specific serial number and date elements in code generation. This avoids relying only on a single cutoff date, but it introduces accounting, code issuance, and runtime accumulation requirements. Define whether counted time means powered time or actual run time, then use a PLC variable whose update and persistence behavior matches that definition.
| Observed issue | Likely design cause | Check next |
|---|---|---|
| Machine locks again after power restoration | Unlock state was volatile, or a battery-backed value was lost | Test the chosen memory with power removed and inspect the retained value. |
| Machine stops on the wrong day or repeats annually | Clock address, date format, or year handling is wrong | Compare the live clock fields against the programmed condition. |
| Screen does not change to the entry page | Wrong panel model, communication variable, or screen constant | Validate panel mapping with a harmless screen-change test. |
| A valid code fails or can be reused | Entry width, numeric representation, comparison, or one-time-use state is wrong | Check displayed digits, PLC value, and consumed-code state. |
Choose persistence that survives the failure you expect
A retentive bit can hold the lockout state through a normal power cycle only while its retention mechanism remains healthy. The legacy design warns that a battery-backed setting can be lost if the battery fails while power is off; then a previously paid machine may return to the unpaid state. Test battery condition and retention on the actual CPU, not just in a simulator.
Where the CPU offers suitable nonvolatile memory, the discussion recommends storing the paid state in flash RAM and changing it with a MOV instruction. Confirm the CPU’s supported memory type, write method, endurance, and retentive behavior in its documentation. Do not assume every CPU in a family has the same nonvolatile capability: the historical exchange specifically distinguishes a 240 from a 250-1 and reports that a flash-memory card had not yet been tested.
Two less durable workarounds were also described: treating a zero value as paid, which can be bypassed by removing power and the battery, or editing the PLC program on a courtesy service visit to bypass the lockout. Neither is a substitute for verified nonvolatile storage when the paid state must persist independently of a battery or field visit.
Route code entry through a verified panel screen
After confirming the panel interface, configure the documented PLC-to-panel variable and the panel’s screen-selection mechanism. The example writes the value corresponding to a “default on payment” screen to the panel variable when the lockout is active. Verify the actual screen constant using the panel project; do not infer it from the example value.
Put a numeric-entry control on the lockout screen and map it to a PLC value. The historical suggestion uses an eight-digit entry represented as a double word. Check the target panel’s entry width, sign/unsigned behavior, and the PLC data representation. A mismatch can truncate digits or make a visually correct entry compare incorrectly. Show a clear status message on the lock screen, but make the panel indication follow the PLC state rather than treating the screen itself as the authority.
Validate the unlock code and prevent repeated use
For a simple fixed unlock, compare the entered value with a configured value, then set the persistent paid/unlocked state and inhibit the date-trip logic. The source specifically recommends disabling the trip rung after a correct code so it does not immediately reassert. Reset or clear the entered value after acceptance if the panel/PLC design permits, and test that a stale entry cannot unlock a later cycle.
For purchased-hour authorization, the described scheme combines the PLC clock’s year, month, and day with a machine serial number, purchased hours, and constants, using arithmetic operations in a unique order. Its stated risks are overflow and codes that repeat or become predictable. Before releasing such a scheme, calculate intermediate values at the maximum supported inputs using the PLC’s actual numeric widths, and test uniqueness across machines, dates, and quantities. A five-to-eight-digit code length was reported, but it is not evidence that a particular algorithm is secure or collision-free.
Password-protecting the PLC program was also suggested to deter casual inspection. That does not replace a safe machine design, contractual controls, or a tested authorization method. Do not expose a payment interlock as a machine safety function, and do not make loss of an authorization bit defeat protective functions.
Make the lockout stop process operation without defeating safety
Use the payment condition to block a new cycle or request a controlled operational stop; keep emergency stops, guards, safety relays, and other protective functions independent. Establish the permitted stop state from the machine risk assessment and process requirements. A lockout that unexpectedly removes power, traps a load, or interrupts a hazardous process can create a greater risk than the payment problem.
For the PLC sequence, make the lockout condition explicit: when the deadline or exhausted allowance is true and the paid state is false, prevent operation, select the lockout screen, and display the defined message. When the correct authorization is accepted, write the persistent paid state and suppress the lockout condition. Define how faults, clock errors, invalid entries, and a PLC mode transition behave. If the machine cannot reach a safe state under the proposed logic, stop implementation and obtain a machine-safety review.
Test the resolving branch through power cycling
Commission the lockout on a controlled test or with outputs safely inhibited. Use the following procedure, recording the PLC values and panel behavior at each step:
- Confirm CPU and panel models, then verify the live clock, panel variable, screen constant, retentive memory range, and code data type against the correct documentation.
- Set a test condition that activates the lockout. Confirm the PLC blocks the intended operation and the panel displays the lockout page and message.
- Enter an invalid code. Verify that the PLC remains locked and that an invalid or partial entry does not change the persistent state.
- Enter the authorized code. Verify that the PLC records the paid/unlocked state, returns to the approved operating screen, and disables the trip condition.
- Cycle PLC power and restart the program. Confirm the machine remains unlocked after authorization and does not re-trip; separately test the unpaid restart path and confirm the lockout returns.
- If using a purchased-hours scheme, verify the remaining allowance, addition of the authorized quantity, rejection of code reuse, and behavior at the configured limit.
Do not release the change until the paid and unpaid restart paths both pass, the lockout cannot bypass safety functions, and the recorded memory values match the intended persistence strategy. The permanent repair is a verified state-storage and authorization design; a battery-dependent bit or field program edit is only a workaround with distinct failure modes.
FAQ
How do I keep a PLC unlock state after a power cycle?
Use a memory location the installed CPU documents as retentive or nonvolatile, then test it through power loss and restart. A battery-backed value can be lost if the battery fails while power is off; validate flash-memory support and its write method for the exact CPU.
How do I make an EZ-SP display a PLC lockout screen?
First confirm the panel model and software: the historical programming example refers to EZ-TP, although the requested panel is EZ-SP. Configure the supported PLC-to-panel screen variable and use the screen constant from the actual panel project; V2000 is only an example.
How do I know when to stop and call official support?
Stop before commissioning if the CPU memory map, panel interface, or safe stop behavior is unclear, or if power-cycle testing loses the paid state. Contact the PLC or panel manufacturer’s official support channel with the model numbers, project version, memory map, and test results.