You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docfx/articles/guidelines/components.md
-24Lines changed: 0 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -123,30 +123,6 @@ Components should surface diagnostic and alarm information consistently:
123
123
124
124
For UI auto‑rendering the alarm level icons provided by `AxoComponent` will reflect the highest active severity; ensure warnings are deactivated when condition clears to avoid stale visualization.
125
125
126
-
### Message Categories
127
-
128
-
The framework supports the following message categories (in order of severity):
129
-
130
-
***None** (0): No category; used to clear requalification directives and ignore non-critical messages
131
-
***Info** (100): Informative messages with minimal impact; do not require operator intervention
132
-
***Potential** (150): Potential problems that may escalate to Warning or Error states; these messages can be automatically requalified based on system configuration when downstream conditions are detected
133
-
***Warning** (200): Possible problems that may adversely affect a process; information to help identify problems but does not necessarily stop the process
134
-
***Error** (300): Failures that cannot be immediately recovered; intervention is needed
135
-
***Critical** (400): Critical system failures
136
-
***ProgrammingError** (500): Implementation or configuration errors in the application
137
-
138
-
When using the `Potential` category, ensure that the parent context or sequencer is configured with appropriate requalification rules to escalate potential issues to `Warning` or `Error` when conditions persist.
139
-
140
-
### Message Requalification
141
-
142
-
For coordinated components and sequencers, message requalification allows upstream components to influence downstream message severity. Use `GetMessengerService().RequalifyDownstreamMessages(category)` to set the requalification category. This is particularly useful for:
143
-
144
-
* Escalating `Potential` messages to `Warning` or `Error` based on elapsed time
145
-
* Implementing hierarchical error response strategies in multi-step workflows
146
-
* Ensuring consistent severity handling across component hierarchies
147
-
148
-
Note: Only `Potential` messages are subject to requalification; other categories retain their configured severity.
IF(NOT _MoveToOutIsSuspended AND NOT THIS._MoveOutTask.IsDisabled) THEN
140
-
_Messenger.ActivateOnCondition(UINT#1, (_MoveToOutIsBusy AND NOT _MoveToOutIsSuspended), eAxoMessageCategory#Potential);
141
-
_Messenger.ActivateOnCondition(UINT#9, (_MoveOutTask.IsDone() AND NOT _OutSensor), eAxoMessageCategory#Potential);
142
-
END_IF;
139
+
_Messenger.ActivateOnCondition(UINT#1, (_MoveToOutIsBusy AND NOT _MoveToOutIsSuspended AND _MoveOutTask.Duration >= T#10S), eAxoMessageCategory#Error);
140
+
_Messenger.ActivateOnCondition(UINT#9, (_MoveOutTask.IsDone() AND NOT _OutSensor), eAxoMessageCategory#Warning);
0 commit comments