WinCC VBScript operator input validation and command gating
This practical guide explains how to validate operator-entered values and control HMI command availability without moving equipment protection or safety logic out of the PLC.
1. Separate HMI validation from PLC command authorization
An HMI can check whether a value looks reasonable and explain why a button is unavailable. It cannot be the only layer preventing an unsafe command. Treat every HMI write as an external request that the PLC must validate.
| Layer | Recommended responsibility |
|---|---|
| WinCC screen | Input format, engineering range, confirmation and operator feedback |
| WinCC User Administration | Role-based access to approved HMI actions |
| PLC program | Mode, sequence, permissive, interlock and command acceptance |
| Safety system | Safety functions and risk-reduction measures |
2. Validate numeric operator input before writing a tag
Read the proposed input, confirm it is numeric, convert it explicitly and reject values outside the approved engineering range.
Function ValidateSetpoint(ByVal proposedValue, ByVal lowLimit, ByVal highLimit)
ValidateSetpoint = False
If Not IsNumeric(proposedValue) Then Exit Function
Dim value
value = CDbl(proposedValue)
If value < CDbl(lowLimit) Or value > CDbl(highLimit) Then Exit Function
ValidateSetpoint = True
End FunctionDisplay the engineering unit and permitted range next to the entry field. Do not silently clamp an operator value unless the approved functional specification explicitly requires it.
3. Write only after validation and confirmation
Sub WriteApprovedSetpoint(ByVal proposedValue)
If Not ValidateSetpoint(proposedValue, 0, 100) Then
HMIRuntime.Trace "Setpoint rejected: invalid range" & vbCrLf
Exit Sub
End If
If MsgBox("Apply setpoint " & CStr(proposedValue) & " %?", _
vbQuestion + vbYesNo, "Confirm setpoint") = vbYes Then
HMIRuntime.Tags("HMI_Setpoint_Request").Write CDbl(proposedValue)
HMIRuntime.Trace "Setpoint request submitted" & vbCrLf
End If
End SubConfirmation is most useful for consequential or infrequent actions. Avoid interrupting routine operation with unnecessary dialogs.
4. Gate an HMI command from displayed operating state
A button may be disabled when the displayed machine mode or readiness state is unsuitable. This gives immediate feedback but remains separate from PLC acceptance.
Function CanRequestStart()
Dim modeValue, readyValue
modeValue = HMIRuntime.Tags("Machine_Mode").Read
readyValue = HMIRuntime.Tags("Machine_Ready").Read
CanRequestStart = (modeValue = 2 And readyValue = 1)
End FunctionUse explicit state values or documented constants. Avoid unexplained numeric values in production libraries.
5. Apply user authorization correctly
Configure permissions in WinCC User Administration and use the supported authorization dynamic or object-model method for the installed release. Test authorized, unauthorized, expired-session and logged-out states.
- Show why the action is unavailable.
- Log consequential command requests with user and timestamp where required.
- Never treat a hidden button as a security boundary.
6. Use request and acknowledgment tags
For important commands, use a PLC handshake instead of assuming that a successful HMI write means the action occurred.
- WinCC writes a command request and optional request identifier.
- The PLC validates mode, permissives and interlocks.
- The PLC accepts or rejects the request.
- WinCC displays acknowledgment, rejection reason or timeout.
7. Test invalid, stale and unavailable states
| Test | Expected HMI behavior |
|---|---|
| Text entered in numeric field | Reject without writing |
| Value outside engineering range | Show allowed range and preserve previous approved value |
| Communication unavailable | Disable request and show connection state |
| User lacks permission | Prevent interaction and show authorization feedback |
| PLC rejects command | Display the returned reason or timeout state |
8. Commissioning checklist
- Document every command tag, unit, range and data type.
- Confirm the PLC validates every HMI request independently.
- Test boundary values, invalid text, communication loss and user-role changes.
- Confirm scripts do not issue repeated writes from cyclic triggers.
- Record approved behavior in the functional specification and backup.
Frequently asked questions
Is disabling a WinCC button an interlock?
No. It is operator-interface feedback. The PLC or safety system must enforce the actual interlock.
Should invalid input be automatically corrected?
Usually it should be rejected with a clear message. Automatic clamping can conceal an entry mistake unless it is explicitly required and documented.
Can VBScript check user permissions?
Yes, where supported by the installed WinCC object model. Prefer configured authorization dynamics and verify the exact API for the deployed release.
