Determine the PR200 Transition Trigger
The documented behavior is level-based: the PR200 changes screens while the transition variable is at a high level. Do not design the request as though the screen change were explicitly triggered by either a rising or falling edge; the available evidence does not establish edge-triggered behavior.
| Variable condition | Supported interpretation | Engineering decision |
|---|---|---|
| High level | Requests the screen transition | Hold the request long enough for the display logic to process it |
| Rising edge | Not confirmed as the direct trigger | Convert the event into a sustained high-level request |
| Falling edge | Not identified as a transition trigger | Do not rely on it without project-specific testing |
Extend the Request with a TP Block
A one-cycle event can disappear before the screen-transition logic observes it. Feed the event into a TP block so the transition variable remains high for at least several average controller cycles. The evidence provides no exact pulse duration, so select and validate it against the measured cycle behavior of the actual application.
change_event -> TP -> screen_transition_variable
Trigger the TP from the required value-change condition. Its output supplies the sustained high level used by the screen transition.
Implement and Verify the Transition
- Generate an event when the monitored variable changes in the required direction or condition.
- Connect that event to a TP block.
- Use the TP output as the screen-transition variable.
- Set the pulse long enough to span several measured average cycles; no evidence-supported numeric setting is available.
- Test repeated changes and confirm that every event produces exactly one intended transition.
A single TP can serve multiple screen-change requests. If requests can occur simultaneously, verify the arbitration and destination-selection logic in the project; the available evidence confirms TP sharing but does not define how concurrent destinations are resolved.
FAQ
Does the PR200 change screens on a rising or falling edge?
The supported behavior is a transition at a high variable level. Rising-edge or falling-edge triggering is not established by the available evidence.
Why does a PR200 screen-change pulse sometimes get missed?
The high level may be shorter than the screen logic can observe. Use a TP block to hold the transition variable high for at least several measured average controller cycles.
Can one TP block control multiple PR200 screen transitions?
Yes, one TP can be shared. Verify the project logic if multiple destinations can be requested at the same time because concurrent-request behavior is not specified in the evidence.