Configuring ScreenMaker 5.11 Visibility from RAPID

A ScreenMaker object stays visible even after RAPID changes the intended state because ScreenMaker 5.11 cannot bind its Visible property directly to a controller object. Use an ActionTrigger to listen for a RAPID variable change, update an application variable in the trigger's Change event, and bind that application variable to Visible. Set the object's default Visible value to TRUE; that initial state is required to start the binding mechanism. Keep screen navigation inside the ScreenMaker structure unless the deployment process also controls RAPID-to-screen dependencies.

Symptom and decision boundary

The number that matters is event timing: the RAPID variable must change, the ActionTrigger must observe that change, and its event must update the application variable before the object can change visibility. This is event-state propagation, not a RAPID binding directly attached to Visible.

Event-driven visibility mechanism

ScreenMaker 5.11 exposes different connectivity rules for object properties. The Enabled property can bind to a controller object and therefore follow RAPID-controlled data directly. The Visible property can bind only to an application variable, which RAPID cannot control through the same direct binding path.

ActionTrigger bridges that gap. It monitors a RAPID variable and raises its Change event when the monitored value changes. The event then assigns the corresponding state to the application variable used by the object's Visible property.

RAPID variable changes
        |
        v
ActionTrigger.Change
        |
        v
Application variable
        |
        v
Object.Visible

The application variable is the ScreenMaker-side state holder. RAPID remains responsible for process and sequence decisions, while ScreenMaker translates a state transition into a presentation change. This arrangement supports conditional object visibility without adding an expression evaluator to the screen definition.

Use a RAPID value whose transitions represent deliberate interface states. A trigger detects change, so repeated writes of the same value may not create a new change event. When the interface must refresh after re-entry or deployment, verify the actual monitored value and the application variable rather than relying on an assumed event.

Binding and control boundaries

The architecture separates controller execution from the FlexPendant application. ScreenMaker applications depend on RAPID data and I/O configuration, but making RAPID navigate named ScreenMaker screens creates a reverse dependency. A renamed screen or missing ScreenMaker application can then leave valid RAPID code pointing at an unavailable user-interface resource.

A project with 40 screens demonstrates why this boundary matters. If RAPID contains references to all 40 names, changing one screen name can create a dormant failure that appears only when the operator eventually reaches that branch. Compilation of RAPID alone cannot validate whether every referenced ScreenMaker screen is present in the deployed application.

ActionTrigger configuration procedure

1. Define the operator decision in RAPID. Reduce the result to a controller variable that represents the display state needed by ScreenMaker. Keep multi-branch process logic in RAPID instead of trying to reproduce IF or WHILE behavior in a ScreenMaker version without an expression editor.

2. Create or select the ScreenMaker application variable that will drive the target object's Visible property. Use a state type compatible with the property's true-or-false behavior.

3. Select the target object and set its default Visible value to TRUE. Perform this before relying on the binding because the initial true value is a requirement for starting the mechanism described for this version.

4. Bind the object's Visible property to the application variable. Confirm that the binding points to the application variable, not directly to the RAPID controller object.

5. Add an ActionTrigger component and configure it to listen to the selected RAPID variable. The monitored variable must change when the operator's earlier selection or RAPID sequence changes the required display state.

6. In the trigger's Change event, assign the RAPID-derived state to the application variable. If the types or meanings differ, make the conversion explicit in the available event action instead of relying on an implicit interpretation.

7. Deploy the ScreenMaker application together with the matching RAPID program and I/O configuration. Treat them as one release set even when the dependency currently runs mainly from ScreenMaker toward controller data.

8. Exercise both state transitions while RAPID runs. Verify visible-to-hidden and hidden-to-visible behavior, then repeat the test after reopening the application or restarting the relevant runtime environment.

For several conditionally displayed objects, one application variable may drive objects that must always change together. Use separate variables where objects have independent states. This keeps the mapping observable and prevents one trigger action from unintentionally changing unrelated parts of the screen.

Runtime verification

Verify each link separately. First watch the RAPID variable and confirm that the operator action changes it. Next observe whether the ActionTrigger Change event runs and updates the application variable. Finally confirm that the object follows the application variable through its Visible binding.

1. Start from the default condition and record the RAPID variable, application variable, and visible state.

2. Make the operator selection that changes the RAPID decision. Confirm an actual value transition rather than only execution of the assignment.

3. Check that the application variable receives the new state through ActionTrigger.Change.

4. Confirm that the object changes visibility without leaving the ScreenMaker application.

5. Reverse the selection and verify the complete return path.

6. Repeat every screen-navigation branch that can reach the object. A successful main path does not test dormant screen-name references.

7. Run a deployment-negative test in a controlled engineering environment: identify how the system reports a missing project or incorrect UIShow parameters, and preserve that diagnostic information for commissioning.

If Enabled changes while Visible does not, RAPID communication is probably intact; inspect the application-variable transfer and the default visibility setting. If neither property changes, start at the controller-object connection and the deployed RAPID data definition.

Screen navigation and deployment coupling

Using ScreenMaker as a richer replacement for TPErase, TPReadFK, TPReadNum, TPShow, and TPWrite changes more than appearance. Those RAPID instructions keep the interaction under controller-program control. A ScreenMaker application introduces separately defined screens, objects, bindings, deployment content, and authorization behavior.

Calls such as UIShow require correct parameters and the associated ScreenMaker project to be deployed. The key risk is not immediate syntax failure; it is a valid RAPID program retaining a reference to a screen that has since been renamed or removed. The fault remains hidden until the exact event and button sequence requests that screen.

Control the dependency with a release checklist. Freeze screen identifiers used by RAPID, search RAPID for each identifier before renaming a screen, deploy the RAPID and ScreenMaker revisions together, and test every reachable navigation branch. Maintain one mapping of RAPID request states to ScreenMaker screen names so a review can detect missing or duplicate destinations.

Closing the Main screen or presenting arbitrary screens from RAPID cannot be treated as a general, unrestricted ScreenMaker 5.11 interface. Design the normal flow around the supported ScreenMaker tree and use RAPID-driven screen requests only where the tested action and deployment arrangement provide the required behavior.

Recurring implementation pitfalls

The first recurring error is treating Visible like Enabled. Their binding capabilities differ, so copying the controller-object binding pattern leaves visibility without a valid RAPID-to-application transfer.

The second is starting the object hidden. For this workaround, default Visible must be TRUE to initiate the binding mechanism. Apply the desired hidden state only after the binding and trigger path are active.

The third is placing interface branching in a tool without script or expression support. Calculate compound conditions in RAPID and expose a clean state for the trigger. If the application needs loops, dynamic discovery, or extensive interface-side logic, RAB is the appropriate design path to evaluate.

The fourth is assuming a deployed RAPID program proves the ScreenMaker package is complete. Screen-name dependencies can fail at runtime after a rename or omitted deployment. Test rarely used combinations, not only the first screen and the common production route.

The fifth is treating presentation as permission. UAS remains part of the action path, and interface design does not replace authorization configuration. Test each protected action with the user roles that will operate and maintain the cell.

Frequently asked questions