Fault Management Blocks

From NewEagleWiki
Revision as of 20:22, 25 January 2012 by Tdougan (talk | contribs) (→‎MotoHawk:Blocks:Fault Definition)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

C

MotoHawk:Blocks:Clear All Faults

Trigger this MotoHawk® block to clear all defined faults. This action is identical to the 'Clear All Faults' selection in the Fault Command popup from MotoTune.

MotoHawk:Blocks:Clear Fault

This MotoHawk® block clears a single Fault, either by name, or using a fault_T input reference. If the 'clear' input signal is true, the fault will be cleared, otherwise, it is not modified.

F

MotoHawk:Blocks:Fault Action

This MotoHawk® block defines a Fault Action, which can have any number of Faults routed to it. This routing can be initially configured at design-time, using the Fault Definition blocks, and can be modified from MotoTune using the Fault Manager calibration.

Each Fault Definition can be mapped to up to four Fault Actions. There is no limit to the number of Faults which can map to any given Fault Action. The output signal is true if any of the routed Faults have their Fault Action Condition met, which is some combination of the Suspected, Active, or Occurred status of the fault.

MotoHawk:Blocks:Fault Action Status

This MotoHawk® block defines a Fault Action, which can have any number of Faults routed to it. This routing can be initially configured at design-time, using the Fault Definition blocks, and can be modified from MotoTune using the Fault Manager calibration.

Each Fault Definition can be mapped to up to four Fault Actions. There is no limit to the number of Faults which can map to any given Fault Action. The output signal is true if any of the routed Faults have their Fault Action Condition met, which is some combination of the Suspected, Active, or Occurred status of the fault.

MotoHawk:Blocks:Fault Activity Trigger

This MotoHawk® block triggers a Simulink Function-Call subsystem, when any Fault changes state as specified. The MotoHawk Fault Activity block may be placed into the triggered subsystem, to determine which fault caused this trigger. More than one trigger may be placed in a model hooking off of the same event. In this case, the 'Priority Order' can be used to order these independent triggers. If the priorities are the same, then the order is implementation dependent.

MotoHawk:Blocks:Fault Definition

This MotoHawk® block defines a Fault, which can be viewed from MotoTune, and may have several calibratable Fault Actions associated with it. Faults are associated with the 'detection' of a fault condition. 'Responses' to fault conditions should be implemented using Fault Action blocks. Also note from the help section about this block, where it talks about sticky-persistent and enabled persistent it says x and y counts are saved over power cycles. This information is wrong, x/y counts are never saved over power cycles, and reset to zero every time keyswitch or power is turned off. The information that is saved is the fault condition, and the x/y limits.

MotoHawk:Blocks:Fault Iterator

Use This MotoHawk® block to iterate through the fault definitions in the Fault Manager Definition, and get a fault_T reference to each one matching a given criteria. This block can be used to iterate through all of the faults, all faults not marked Disabled, the suspected faults, the active faults, or the occurred faults.

Input a fault_T reference, and the next fault will be output. If a null fault_T is provided at the input, the first fault will be output. If no faults are available matching the given criteria, then the block will output a null fault_T, and the Valid output will be false.

Because the output is null at the end of the iteration, it may be used as the next input, starting the iteration over. To skip the null fault_T, and simply loop back to the beginning, check 'Continue looping through faults.' When this is checked, the Valid will remain true, and there will be no way to determine when the loop starts over. Of course, if no faults are available, the output will be null and Valid will be false.

MotoHawk:Blocks:Fault Manager Definition

This MotoHawk® block defines the Fault Manager, and must exist once in each model that contains Fault blocks. Code is generated to cache the faults in a memory-efficient manner, and An interface is generated in MotoTune to display and configure the faults. The X/Y Storage Type affects how large the X out of Y counts may be, but increases total RAM and FLASH usage.

MotoHawk:Blocks:Fault Name

This MotoHawk® block outputs the name of a fault, given a fault reference using the fault_T data type. The name string is output as a null-terminated vector of uint8 bytes, using ASCII characters. The width of the output is supplied as a parameter, but is often set to: "size(char(motohawk_get_faults),2)+1" This expression gives the maximum name length, plus one for the null-terminator.

MotoHawk:Blocks:Fault Properties

This MotoHawk® block outputs various properties about the given fault, either by name, or using a fault_T input reference.

MotoHawk:Blocks:Fault Reference

This MotoHawk® block outputs a fault reference to the given fault by name, using the 'fault_T' data type.

MotoHawk:Blocks:Fault Status

This MotoHawk® block retrieves the current Fault Status, either by name, or using a fault_T input reference. The output may be one of the states Suspected, Active, or Occurred, or all three.

MotoHawk:Blocks:Fault Statuses

This MotoHawk® block retrieves the current Fault Statuses by name for a list of faults. A helper function, motohawk_get_faults(sys), will get all of the faults in the model sys. The output may be one of the states Suspected, Active, or Occurred, or all three.

MotoHawk:Blocks:Fault T to Integer

This MotoHawk® block converts the custom fault_T data type, which is output by a MotoHawk Fault Reference block, into a uint32. Note that using the value of a raw fault_T is highly unpredictable, and not recommended. This is here primarily for debugging fault references, because Probes cannot be directly connected to a fault_T type.

MotoHawk:Blocks:Fault T is Valid

This MotoHawk® block outputs true if the given fault_T reference is not null.

L

MotoHawk:Blocks:Last Active Fault

This MotoHawk® block outputs a fault_T reference to the last fault to become Suspected, Unsuspected, Active, Inactive, or Occurred. When placed in a subsystem triggered by a Fault Activity Trigger, this block can be used to determine which fault caused the trigger.

N

MotoHawk:Blocks:Null Fault T

This MotoHawk® block outputs a null fault_T . This can be useful when providing the initial condition to a Fault Iterator.

P

MotoHawk:Blocks:Previous Fault T

This MotoHawk® block outputs the previous fault_T. This block is equivalent to a Unit Delay, except that it works with the fault_T data type, and has no Initial Value parameter. The initial value of this block is always a null fault_T.

S

MotoHawk:Blocks:Set Fault

This MotoHawk® block sets the Suspected status of a fault, defined elsewhere using the Fault Definition block, either by name, or using a fault_T input reference.

If the input signal is true, the fault becomes Suspected until the count reaches X out of Y samples, when it becomes Active. The fault becomes inactive again after Y samples of false input.

If Update X/Y Counters is checked, the X/Y counter state is updated once every Downsample Count executions of the block.

U

MotoHawk:Blocks:Update Fault

This MotoHawk® block triggering this MotoHawk® block causes the X/Y counts and suspected, active, occurred states to be updated for the given fault. This action is normally performed by the Fault Definition and/or the Fault Set blocks, but this block allows independent access to the underlying mechanism.