 |
|
|
Allows the application to configure the Flexible Encoder's Synchronizer Slip feature. Often used with the Synchronizer Slip Get block.
Sync Slip Set
motohawk_flexenc_lib
The Flexible Encoder's Synchronizer Slip feature allows sources that utilize a runtime NX (Equidistant) pattern and a synchronizing companion to be more tolerant to variations in in the synchronizing source's signal. This block can be used to allow the encoder system to better manage variations in synchronizer phase and/or be more noise tolerant.
This feature does not impact the behavior of other patterns including a user-defined NX type pattern defined explicitly in XML. This feature is only applicable when using the NX runtime pattern.
A 151 equidistant tooth crank encoder that runs a single tooth synchronizing companion via its cam is one example of such an encoder system.
Synchronizer slip allows the application to define a runtime tunable window within the cycle where the synchronizing event is expected to occur. This is referred to as the slip acceptance window. It is different from a Sync Companion Window in that it is defined relative to a qualified position about the cycle rather than relative to a key. Note that an NX pattern has a semi-unique key associated with each of its teeth so the Sync Companion Window is irrelevant for such a pattern.
That an NX pattern has semi-unique keys on each of its teeth means that the encoder system needs to be told when the observed synchronization is considered appropriate. This is referred to as qualification and is supplied by the application via the Qualify signal. The encoder system will behave in the traditional manner (as if the block had not even been included in a model) until the application qualifies the synchronization. Qualification might be as simple as observing some number of revolutions without any errors.
Qualification is runtime controlled so the application can choose to remove qualification at any point in time, which will restore traditional operation.
The Request Advance and Request Retard signals are used to set the slip acceptance window. Advance defines the region ahead of the qualified synchronization point that an observed synchronization event is still considered acceptable and retard defines the region behind the qualified synchronization point.
The slip acceptance window resolves to teeth within the encoder's implementation. The engineering values are converted to teeth values and the impact of rounding reflected in the reported Allowed Advance and Allowed Retard values. Slip is always calculated relative to a physical tooth so a non-zero value of retard will immediately translate to a non-zero tooth value for retard. Conversely advance will always have the region that proceeds the physical tooth and so requesting zero will still result in a non-zero value for acceptable advance.
Once qualified, a synchronization events that is observed outside of the slip acceptance window is ignored (and a slip fault flagged) such that there is no impact to the tracked position. In most cases a synchronization fault can't result while the source is considered qualified.
Some variants of an NX have a high tooth count and are used with synchronizing sources that have a degree of slip in their assembly. Such systems, during their normal operation, experience a change in phase of the synchronizing event. Such phase changes, when experienced by MotoHawk's traditional implementation of an NX encoder with synchronizer, would see the encoder source issue synchronization faults and attempt to re-synchronize to the new event. This is problematic if the phase change is system induced and unavoidable.
This feature allows the situation like the one illustrated above to be handled without generating any errors. The Request Advance and Request Retard signals offered by this block allow the region of legal phase change to be defined. Observed synchronization events that occur within this region are considered legal while the encoder system is marked as qualified without resulting in any errors. The Synchronizer Slip Get block provides a method to monitor actual position of the synchronizer and can be used to tune the size of the slip acceptance window.
A side effect of using this strategy is the improved noise tolerance that it also provides. However the application does have some further responsibilities to consider when using this block too. See Double Jeopardy.
MotoHawk's traditional means to implement an NX encoder with synchronizer is to treat the synchronizing companion as faultless. Thus any synchronizing event observed on the synchronizing source is faithfully used to re-synchronize the NX pattern. Any erroneous synchronizing event will result in false re-synchronization of the dependant source. Patterns with complex keys are less susceptible to such erroneous synchronizing events. However systems that use single tooth pattern as the synchronizing source, which is quite common, are quite susceptible to these erroneous re-synchronizations because a noise pulse can't be distinguished from a real tooth.
An erroneous synchronizing event will cause a synchronization fault to be issued and the encoder system will incorrectly alter its tracked crank angle position. This can, in turn, result in a sequence of bad crank synchronous actuations (missed and/or repeated) being generated. The error is then soon followed by another synchronization fault as the source recovers from the earlier resynchronization event when it observes the real tooth event.
The slip acceptance window allows a tolerance to noise to be installed by providing a way to ratify whether the synchronizing event occurred where it was expected whilst still communicating with the application that there is a potential problem. When the application flags a source as qualified it is telling the encoder system that it can now ignore observed synchronizing events that fall outside of the slip acceptance window and instead flag them as slip faults. These do not impact the tracked position unlike synchronization faults, which do. In essence it allows the application to alter the assumption that the synchronizing source is faultless.
Just setting the requested advance and requested retard each to zero would convert a traditional MotoHawk NX encoder with synchronizer setup into one that was more tolerant to noise.
If noise can be observed on the synchronizer then it stands to reason that it could also occur on the Absolute Source too. MotoHawk will attempt to detect noise and flag a Noise Suspected fault when noise is suspected. The encoder will not ignore the next synchronization event, even when marked as qualified, if the Absolute Source noise flagged that is suspects noise. Instead it will attempt to re-synchronize the Absolute Source using the next observed synchronization event.
Double Jeopardy
Noise on one source could mean noise on both sources. In this situation neither source can really be trusted, but the encoder must still choose one source
and so it selects the synchronizing source. A system that is marked as qualified and experiencing noise on both sources could synchronize using a noise pulse
instead of the pulse created by the real tooth. The issue here is that because the encoder is considered qualified, synchronization events observed subsequent
to this noise pulse will likely be ignored because they now fall outside the slip acceptance window.
Slip faults will be flagged in this situation and the encoder won't re-synchronize.
The encoder will not automatically recover from this situation while the encoder is marked as qualified. The application must monitor for and handle this situation. A potential application solve is illustrated in the figure below. The motohawk_flexencoder_project script when used with the 'Cnk_151X_Cam_Tooth' encoder_system_type includes this code.
Continuous slip faults should not be considered normal. The application should consider disabling qualification for a time so that the encoder can re-qualify its position if this situation is observed. Alternatively it should force a stall condition.
| Parameter Field | Values | Comments/Description |
|---|---|---|
| Reference Source Name | Alpha-numeric text, quote enclosed | The name of the Absolute Source that is to have its Synchronizer Slip attributes modified. |
Setting this signal to true enables the synchronizer slip strategy. When the application transitions this signal to true the encoder system will record the next observed synchronization point as the qualified synchronization point. The physical position within the cycle can be recovered with the Synchronizer Slip Get block.
The request is ignored if the source is not synchronized.
Defines the advance portion of the slip acceptance window. It has units of x16 degrees Crank Angle and defines the region ahead of the NX tooth associated with the qualified synchronization point that an observed synchronization event is still considered acceptable. Advance on an encoder a signal trace is the portion to the left of tooth#0.
Use the Allowed Advance signal to discern how the encoder system translates the requested advance into a value that accounts for the tooth nature of the underlying implementation.
Defines the retard portion of the slip acceptance window. It has units of x16 degrees Crank Angle and defines the region behind the qualified synchronization point that an observed synchronization event is still considered acceptable. Retard on an encoder a signal trace is the portion to the right of tooth#0. Requesting any non-zero value of retard will immediately imply that at least one tooth of slip to the right is acceptable.
Use the Allowed Retard signal to discern how the encoder system translates the requested retard into a value that accounts for the tooth nature of the underlying implementation.
Represents the encoder system's interpretation of the Request Advance signal. The slip acceptance window is implemented within the encoder system via a tooth monitor. Thus the implementation rounds the requested advance to a tooth value, which then represents the amount of advance that will be allowed.
Represents the encoder system's interpretation of the Request Retard signal. The slip acceptance window is implemented within the encoder system via a tooth monitor. Thus the implementation rounds the requested retard to a tooth value, which then represents the amount of retard that will be allowed.
The m-script motohawk_flexible_encoder_syncslip_enum enumerates the status.
This status is returned if the referenced Absolute Source failed to create. This typically suggests an application problem where the Absolute Source is not referenced by the System block.
The Synchronizer Slip feature is only applicable to Absolute Sources that utilizes a synchronization companion. This status is returned if the block references an Absolute Source that does not have a synchronization companion or if a synchronization companion has been defined, but it has been disabled.
This status is returned if an Absolute Source is queried that utilizes a synchronization companion, but employs a pattern that is not supported by this feature. Currently the synchronizer slip feature is only applicable for an Absolute Source that uses a runtime defined NX (Equidistant) pattern.
This status is returned if the Absolute Source has not yet achieved synchronization. Synchronizer slip data is not valid until the source has achieved synchronization.
This status is returned while the qualify signal is false and the referenced Absolute Source has achieved synchronization. It implies that the Flexible Encoder system is waiting for the application to mark the observed synchronization as qualified.
This value will also be returned by a source that has been flagged as "qualified", but has yet to observe a synchronization event since the application applied the flag.
This status is returned while the qualify signal is true and the referenced Absolute Source has achieved synchronization. The Flexible Encoder's Slip Strategy is active when this status is returned.
| Copyright 2015 Woodward Corporation. All Rights Reserved. | Visit Us: mcs.woodward.com |