SMH4 Password Access: Troubleshooting One-Scan Reset

On an SMH4, a password can be accepted while the built-in control-enable signal returns to zero after one FBD cycle. First determine whether that signal is an authentication event pulse or a maintained authorization state. For the reported installation, Setup_Logix_3.32.0069 prevented password-protected values from being changed; reverting to Setup_Logix_3.32.0035 restored operation. A separate check of Setup_Logix_3.32.0076 found the standard block operating with a pulse, so the pulse alone is not proof of a fault.

Identify the Failure by Its Complete Symptom

The standard password-entry form accepts the correct password and performs the screen transition configured in SMART. Online monitoring then shows the built-in control-enable bit at one for a single program cycle before it returns to zero.

Do not diagnose the installation from that transition alone. The decisive functional symptom is whether protected values remain editable after authentication. Use the following distinction:

In this case, the second row identified the actual fault under Setup_Logix_3.32.0069. Formatting the panel and updating or reloading the software did not change the result.

Understand the One-Cycle Authorization Pulse

An HMI authentication object commonly separates an event from a state. The event indicates that a valid password was submitted. It may remain true for only one FBD execution cycle so downstream logic can detect a new authorization without repeatedly executing the same action. A maintained permission, session, access level, or internal runtime flag must then govern the protected controls.

If the project uses the event output directly as the enable condition for protected values, those values will be writable only during the scan in which the pulse is true. By the time the operator touches a protected field, the enable condition is already false. A project can also fail when the runtime accepts the password but does not transfer the event into its maintained permission state.

Trace the signal through three layers:

1. Authentication: Confirm that the password form recognizes the correct password.
2. Event processing: Confirm that the expected one-cycle pulse reaches the FBD logic.
3. Permission enforcement: Confirm which state the protected control evaluates when the operator attempts to write a value.

The screen transition proves that at least one valid-password action executed. It does not prove that the protected control sees a durable authorization state.

Run a Version-Controlled Diagnostic Sequence

1. Record the SMH4 project, runtime package, and installed Setup_Logix version before changing anything.
2. Start online monitoring and watch the password result, the built-in control-enable output, any project latch or access-state variable, and the enable condition used by one protected field.
3. Enter an incorrect password. Verify that no success pulse, protected screen transition, or access state is produced.
4. Enter the correct password. Record whether the screen changes, whether the output pulses for one cycle, and whether a maintained permission changes afterward.
5. Attempt to edit a protected value after the pulse has returned to zero. Separate a display-navigation success from a permission success.
6. Repeat the same test on a known-working SMH4 or with the known-working software version. Keep the project and operator sequence unchanged so the software version remains the controlled variable.
7. Restart the runtime and repeat the test. This checks whether an earlier session or retained state affected the result.

A useful trace must include both the pulse and the signal ultimately consumed by the protected object. Monitoring only the built-in output can make correct pulse behavior look like a reset defect.

Recover the Affected Installation

The confirmed recovery for the affected SMH4 was to replace Setup_Logix_3.32.0069 with Setup_Logix_3.32.0035. Treat this as a controlled software rollback, not as a project-format repair.

1. Preserve the current project and record the installed package version.
2. Install Setup_Logix_3.32.0035 using the normal deployment process for the panel.
3. Load the same project without changing its password logic.
4. Execute the diagnostic sequence again with both incorrect and correct passwords.
5. Verify that the operator can modify protected values after authentication, not merely that the destination screen opens.

Formatting did not resolve the reported behavior because it did not remove the operative version difference. Repeating a reload without changing the relevant runtime component is therefore a low-value test once the project works on other SMH4 panels.

Evaluate Setup_Logix_3.32.0076 Correctly

Setup_Logix_3.32.0076 was separately checked and the standard block operated with a pulse. That result establishes an important diagnostic rule: a one-cycle pulse can be normal block behavior. Qualification of this version for a production project must still test the complete access sequence with the actual project.

1. Deploy the unchanged project to a test SMH4 running Setup_Logix_3.32.0076.
2. Confirm the valid-password pulse and screen transition.
3. Wait until the pulse returns to zero, then edit every class of protected value used by the application.
4. Test logout, runtime restart, and an incorrect password to confirm that access is removed at the intended boundaries.
5. Compare the observed state transitions with the block help for that installed version.

Accept the version only when protected writes succeed for the intended authenticated session and fail outside it. Do not use pulse duration as the sole acceptance criterion.

Avoid Recurring Password-Control Pitfalls

Do not convert the authentication pulse into a permanently latched enable without defining a reset path. If project logic must retain authorization, reset it on every required security boundary, such as logout, session termination, runtime initialization, or another application-defined event.

Keep navigation and authorization tests separate. An automatic screen change confirms that the password action fired; it does not confirm write permission. Likewise, a visible online pulse confirms event generation but not successful enforcement by the target object.

When comparing panels, hold the project, password, test field, and operator sequence constant. Record the complete Setup_Logix version because the same application can behave differently across runtime builds. Finally, verify both positive and negative cases: the correct password must grant the intended access, while an incorrect password and the defined logout path must deny it.

FAQ