 |
|
|
The Flexible Encoder allows an XML encoder pattern definition to be included in a model. This gives the application the flexibility to tailor the definition to take into account various nuances of the pattern's operation, including the strength of the pattern matching used to synchronize that pattern. This block is used to reference an XML definition within the model. Use the Encoder Pattern Path Block to specify the location of custom pattern definitions.
Encoder Pattern Definition
motohawk_flexenc_lib
| Parameter Field | Values | Comments/Description |
|---|---|---|
| Name | Alpha-numeric text, quote enclosed | Choose a C-legal name for this encoder pattern. Blocks like the Absolute Source Definition Block will use this name to reference the encoder. |
| Pattern | Alpha-numeric text, quote enclosed | The value of the DescriptiveName node of the pattern within the XML definition that is to be assoicated with this block. MotoHawk will associate the identified XML definition to this encoder definition block. |
A Flexible Encoder XML encoder pattern definition must contains the following nodes within an < Encoder > node (unless the node is marked as optional):
Name is typically matched to the file name and is optional.
DescriptiveName identifies this encoder pattern definition to MotoHawk. This name should be unique for all the encoder patterns supported by a model. MotoHawk does provide some default encoder definitions and this could be grown over time. There will never be a namespace clash if the encoder definitions that are authored by the developer prefix the value of DescriptiveName with 'custom'.
Enter the value of the DescriptiveName within Pattern block entry to have the MotoHawk block reference this encoder pattern definition.
PhysicalTeeth houses the definition of the encoder pattern's tooth arrangement. Each tooth should have a Name and a LogicalDeg node. Optional attributes include StartDeg and EndDeg
Name is the tooth name and by convention is a number that starts at zero and increments with each definition.
LogicalDeg defines the angle about the wheel relative to tooth zero (which is zero degrees) that the synchronous edge of the pulse train that would result when that tooth was observed. The synchronous edge is set by the Sync Polarity a source block and should correspond. Convention dictates that tooth zero should be selected to be the start of a series of similar tooth definitions. In the following example, where an 18 minus 1 pattern is defined, tooth zero is identified as the first tooth after the missing tooth. This ensures that all of the teeth have the same spacing from one another, which helps optimize internal performance.
What follows is a partial definition of the 18 minus 1 crank encoder source depicted in the diagram. Note that the diagram has been drawn in the cam angle domain so that it can be used to explain the relationship between a cam encoder source and a crank encoder source (which rotates twice for a single rotation of the cam). The 18 minus 1 crank encoder pattern does not have two missing teeth. It has just be drawn twice to account for the two rotations that the crank source will undergo for a single revolution of the cam source.
StartDeg are EndDeg optional nodes that have no bearing on the definition. These could be used to encode information that would allow the wheel to be drawn by a graphical tool. Only LogicalDeg is important as it is this angle that the encoder definition will associate the tooth to.
This attribute identifies what the approximate equidistant tooth displacement of the encoder pattern being defined. The 18 minus 1 encoder wheel has an EquidistantToothDisplacement_deg of 20 degrees. This attribute is used to assist pulse scheduling engine when this encoder pattern is in use. Some encoder patterns, like a tooth cam, are not used for pulse scheduling. A pattern like a tooth cam is a companion pattern that may only be used to provide half cycle information. However it still constitutes a pattern and as such this node should still exist, it would just have a value of of 360.
Keys define the key(s) for an encoder pattern. These would be identified by the developer. A key is a pattern that is used by the flexible encoder system to faciliate pattern synchronization. Pattern synchronization needs to occur before the encoder system can associate each observed tooth to a specific angle on the encoder wheel. The flexible encoder observes the input signal(s) and searches that signal for a key(s). There can sometimes be more than one.
A Key is constructed from a sequence of Ratio values. A ratio of tooth displacements is invariant for constant speed of rotation, regardless of the speed of rotation, and thus allow variations in tooth to tooth displacement to be identified. Consider a tooth that is removed from a wheel of equidistant teeth (commonly referred to as a missing tooth pattern). The missing tooth provides a synchronization marker because it uniquely identifies a point on the wheel. The ratio of angle displacements just before and after the missing tooth will be 1.0, 2.0 and 0.5. Neighbouring teeth are separated by the same displacement and so will have a ratio of 1.0. The ratio between the missing tooth region and the previous equidistant tooth will be 2.0, whilst the first tooth after the missing will have a ratio of 0.5 (because the displacement of this tooth when compared to the previous tooth is half). The encoder system can calculate displacement ratio by measuring the time taken to traverse the teeth. The time taken to traverse a displacement is proprotional to displacement for constant speed of rotation so tooth displacement ratios can be inferred by taking the ratio of neigbouring tooth periods (the time observed between teeth). Thus the encoder system could search for a ratio of 2.0 and know that the tooth after the missing tooth had just occurred. Alternatively it could search for 1.0 followed by 2.0 as this is also unique. DefaultKeyTolerance allows constance a speed of rotation to be assumed by installing a window of acceptable ratio values.
Note that whilst the key "2.0" or the key "1.0, 2.0" are both unique, a system could not define both of these keys because a unique key shall not contain the entirety of another key. It would also serve no purpose to detect both keys.
The width of a tooth can also be used for pattern detection. Thus Keys may have a type that is either toothperiod or pulsewidth. Use toothperiod when the Ratio is constructed from adjacent tooth periods. Use pulsewidth when the Ratio between the tooth period and the tooth's width is to be used to construct the key. All the defined keys will interpret Ratio in the same manner.
A pattern may support more than one Key and there are also different types of keys.
A key is constructed from a sequence of KeyValue that are housed within a KeyValues node. Each KeyValue has a Tooth and a Ratio node.
The most common key type are those that are used by the encoder system to calculate the position on the wheel. In other words, the encoder is able to determine the position of the last observed tooth about the wheel when an entire key match has occurred.
ToothPosition is used to define the tooth position a particular key will detect. The diagram below illustrates a 3 tooth key. Note that ToothPosition has the value of 1, which corresponds to the last Tooth in the key. So this key detects tooth position 1. The encoder system knows that it has just observed tooth #1 whenever it observes this key on this encoder source. It knows this because the type is standard unique. Standard keys provide positional information. A standard key that is unique means that this key definition only exists once within the pattern. The construction of this key and the use of ratio is further detailed here. ToothPosition is optional/meaningless if the type is not a standard key.
| type= | Definition |
|---|---|
| standard unique | Standard keys provide positional information. A standard unique key shall only exist once within the pattern and thus will convey absolute position if that key is ever observed. |
| standard semi unique | A standard semi unique key provides positional information, but is not unique. The 3x20M2 pattern contains a semi-unique key. A semi-unique key requires a synchronizing source to exist that will provide an event that can uniquely identify one of the semi-unique keys. See here for an example. A standard semi unique key implies that there are multiple keys that are the same (there are 3 instances of the semi-unque key in the 3x20M2 example). However only one instance of the key would be defined and it's ToothPosition would be configured for the semi-unique key instance that will be marked as unique by a companion synchronizing source. |
| signal inverted | A signal inverted key does not provides positional information. Instead it is looking for a pattern that may occur if the sensor of the encoder source is not connected correctly. It would be used as a diagnostic. See here |
| companion support | A companion support key does not provides positional information. Instead it is used to convey an occurrence event that another source is looking for. A single tooth synchronizer pattern would utilize a companion support key to signal a source with semi unique keys when it occurred so that one of those semi-unique keys could be marked as unique (because it is the first to occur after the companion support key). |
A Key that has no values is referred to as an edge key. Every observed tooth of an edge key is considered to be a key. A tooth cam like the example below or a 36 equidistant tooth wheel would utilize such keys. The 36 tooth wheel would supply positional information and so its key type would be standard semi unique rather than the companion support that can be seen in the ToothCam example below.
This is a convenient marker to associate a key value entry to a PhysicalTeeth Name entry. The circled values in the diagram below illustrates the relationship between a physical tooth and the key value.
Ratio defines the expected matching relationship at this tooth. The relationship always relates to measurements that occur prior to observing the synchronous edge of the signal (which corresponds to a LogicalDeg entry).
When toothperiod matching is in use the ratio is defined as the angular advancement of the tooth previous to the tooth under examination divided by the angular advancement from the previous tooth to the tooth under examination. The diagram above highlights this with colors. Consider If the Ratio determination for Tooth#0. Tooth#0 is under examination and is the first tooth after the missing tooth. It is 40 degrees advanced from the the previous tooth (because there was a missing tooth and each tooth is nominally displaced 20 degrees apart). The tooth previous to the tooth under examination (Tooth#0) is Tooth#16 and it is 20 degrees advanced from the tooth previous to it (Tooth#15). Therefore the Ratio is 2.0.
If pulsewidth were being used then the ratio is defined as the width of the tooth divided by the degrees of advance from the previous tooth. Such ratios should always be smaller than 1.0. The diagram below illustrates a pulsewidth based key. Note that there can be more than one key.
Standard keys convey position and are thus expected to always be observed. An absent key fault or missed key fault results when an expected key is not observed. An absent key is detected by noting how many encoder source teeth have been observed since the last standard key was observed. The TeethBeforeAbsentKeyFault attribute allows the developer to define this value for their pattern.
An appropriate value for this attribute would be 19 if the 18M1 example pattern was in use. The encoder system expects to observe the missing tooth key once per revolution and there are 17 physical teeth per revolution. However rotation may initially start within the key, which is 3 teeth wide for this particular version of the 18M1 pattern. The key won't match unless the entire key is observed and thus starting within the key will not result in a match. Therefore it's possible to legally observe 17+2 teeth and still not have observed the key.
For the 4 toothed pulsewidth the value would be 3. There is more than one key so a key should always have been observed before a full rotation has occurred.
Most key pattern matches are based upon a sequence of ratio matches. These are specified as an absolute value, yet successful matches will require an acceptance band to be defined because the signal will have variance. The DefaultKeyTolerance attribute defines this value. Plus or minus DefaultKeyTolerance is applied to each key value to create an acceptable key range. The value saturates to zero or to a maximum. Thus the lower acceptance value for a ratio value of 0.25 when used with a DefaultKeyTolerance value of 0.3 would be 0.0.
The following missing tooth example illustrates how the tolerance works and why it is needed. The simple missing tooth key looks for a ratio of 2.0. Under acceleration this ratio won't be observed yet the missing tooth has clearly occurred. To reliably detect this key requires a tolerance value of 0.4 to be used. This creates an acceptance window of 1.6 to 2.4, which 1.64 falls within. If the tolerance had been 0.3 then the observed ratio of 1.64 would not have qualified as a legal key match because it falls outside the 2.3 to 1.7 window.
Some encoder sources can be used to provide halfcycle information. Such sources are located on a camshaft and are used to identify which halfcycle a particular engine revolution is associated to (the crank shaft rotates twice as fast as the camshaft). Therefore, from the perspective of an encoder pattern, any pattern could technically be utilized as a halfcycle source. In reality only certain patterns are capable of operating as a halfcycle source, but, so as to avoid having to distingish them, all patterns definitions are assumed to be capable and therefore they all shall support the following attributes:
This attribute specifies how half cycle is encoded. There are three possible schemas, key state, pin state and windowed.
| HalfCycleEncoding | Description |
|---|---|
| state | Used when the pattern supports standard unique keys. Such patterns are able to synchronize themselves without assistance from a companion source. Therefore, once synchronized, the source can be queried for its current position and that position used to indicate whether the system is currently in the first or second half of the cycle. This decision is made using the ClrHalfCycleTooth and set SetHalfCycleTooth attributes. |
| pin | Used when the state of the sensor pin implies the halfcycle state. So a halfmoon sensor could use this style of encoding. To be valid the pin state must reflect the correct halfcycle for each standard unique key that is defined on the absolute source. For example, an 18M1 crank shaft encoder could utilize pin HalfCycleEncoding if the pin would be high around the missing tooth (where the key would likely be defined) for one rotation. pin HalfCycleEncoding is assumed to always be available to the encoder system, which implies that the pin state of the companion will always represent the halfcycle state when a standard unique key is observed on the absolute source that requires the halfcycle information. |
| window | Window encoding is used when the pattern does not support any of its own standard unique keys and the pin state of the pattern does not align with the keys of the absolute source that requires the halfcycle information. The 18M1 with tooth cam figure would utilize the window approach because a tooth cam can't support state or pin encoding. The window defines the region of teeth relative to the standard unique key of the crankshaft source. The 18M1 waveform highlights the halfcycle window. Note that the tooth cam pulse only occurs relative to every second missing tooth (because it rotates at half the speed). Importantly, window halfcycle encoding has been implemented such that it can only be utilized on companion source that has a single standard unique key. If the source in use has more keys than this then all but one of the keys should be deleted so that it will work with the window approach. |
Used with HalfcycleEncoding of state, this attribute clears the halfcycle Boolean when this tooth is observed.
Used with HalfcycleEncoding of state, this attribute sets the halfcycle Boolean when this tooth is observed.
Care should be taken when tuning SetHalfCycleTooth and SetHalfCycleTooth. Often a number of legal settings are possible, but some will have advantages over others. Two options are presented in the figure below. Settings 2 is equally as valid as Settings 1, but Settings 2 has some advantages.
The half cycle doesn't change state near the crank key for the Setting 2 configuration. This allows the possibility that the halfcycle companion could detect a loss error before it was queried to provide halfcycle state. The halfcycle state read by the crank encoder when it detected the missing teeth would not be correct if loss of the half cycle companion occurred between tooth #4 and tooth#0 for the Setting 1 configuration (because tooth#0 wouldn't be observed and so the past state would be maintained). With the Setting 2 configuration the state would still be correct when initially entering into the loss condition. The loss could be detected before state was next queried so the status quo would be maintained since a source in fault is never queried
Secondly, if the 4P1 pattern were being used in a Variable Cam Phaser arrangement, then the Setting 2 configuration must be used because the halfcycle state must remain consistent when queried. If the cam could move then it is conceivable that tooth #0 could move to be before or after the crank encoder's missing teeth. The Setting 1 configuration would report different halfcycle states depending upon whether tooth#0 occurred before or after the crank encoder's missing teeth, which wouldn't be the case for the Setting 2 configuration.
| Copyright 2010-2012 Woodward Corporation. All Rights Reserved. | Visit Us: mcs.woodward.com |