Flexible Encoder

Why Flexible Encoder?

It can be expensive to add a new hand coded encoder pattern to MotoHawk both in terms of dollar cost and time cost. The Flexible Encoder allows the user to specify their exact Encoder Specification using an xml file. Also, classic encoder patterns as defined in the Encoder Definition Block are generic. For example, the 60-2 crank; single tooth cam was the same for all users. There was no way to tune the encoder behavior based on system characteristics. With Flexible Encoder, the overall encoder design is shifted to the customer. Therefore, the encoder can be designed for the customer specific application. Teeth location, Keying/Pattern matching, Fault behavior, Impact of Wheel Acceleration, Source Interaction, .. can all be specified specific to the user's application.

  The Flexible Encoder offers powerful flexibility over the encoder system design, but also greater responsibility 

Flexibility

• Tooth Displacement
  
• Key Strength
  
• Number of Keys - can have multiple key points on the wheel
  
• Source Phasing - you now control how the two, three sources interact in terms of phasing
  
• Diagnostic Controls
  

Enhanced capability and new features

• Multiple source solutions
  
• Active encoder switching - switch between multiple encoders
  
• Additional diagnostics
  
• Improved RPM sampling - more flexibility in how that works
  
• New RPM value - Cycle RPM
  
• Interpolative TDC and Angle Event Triggers - in classic implementations angle based triggers were on physical teeth. Flexible encoder interpolates.
• Implicit Phase Reporting - variable cam .. can measure the phase between one source and another.
  

Requirements

MotoHawk Requirements

MotoHawk 2012a or higher is required for Flexible Encoder <br\> <br\> <br\>

Module Requirements

Flexible Encoder is supported on PCM09 (ECM-5554-112-090x) and ECM-OH (ECM-5644A-112-048-120x).

An Enhanced Time Processing Unit (eTPU) is required for Flexible Encoder, so the Flexible Encoder cannot be supported on the 48, 80, or 128 pin module as these do not have eTPU.

Differences Between Flexible Encoder and the Classic MotoHawk Encoder

The Classic Encoder is a one-size fits all Encoder, implemented through an Encoder Definition Block. The Application Designer selects their encoder pattern in a drop down menu. The Flexible Encoder offers requires more application design of the encoder system, but is as the name implies much more flexible and offers additional power over the encoder design as well as additional features. Some of the differences are outlined below.

1. Interpolative Triggers: <br\>

• The Classic Encoder triggers on physical teeth.
• The Flexible Encoder provides for an interplation between teeth.

2. RPM Calculations: Average and Cycle RPM <br\>

• In Classic Encoder, RPM is defined by the Encoder System's TDC and Missing Teeth contributed to average RPM.
• In Flexible Encoder, the Application Designer controls separately where average RPM is calculated. RPM Sample Points is a vector setting in the Source Definition Block.
• Average Cycle RPM is a also new calculation feature of the Flexible Encoder.

3. How Teeth Are Handled: The flexible and classic encoder systems differ in terms of how they handle missing and extra teeth.

In Flexible Encoder, All Physical Teeth Matter, and ONLY Physical Teeth Matter. In Classic Encoder, Missing Teeth Contribute to the System.

All Teeth Matter

In a 4+1 pattern the extra tooth matters for the flexible encoder. So, the tooth's position needs to be defined precisely. It contributes to instantaneous RPM, and provides a High-Res trigger event.

In classic encoder the extra tooth doesn't matter - it is only used to synchronize.

No Concept of Psuedo Teeth.

In flexible encoder, you won't get High-Res trigger events from the missing teeth.

The classic encoder would provide a High-Res trigger event on missing teeth.

4. Additional Diagnostics:<br\>

• Flexible Encoder allows for additional fault reporting, Synchronization Fault, HalfCycle Fault, Loss Fault, Inversion Fault, Phase Fault, Absent Key Fault, Reverse Rotation, Bad Halfcycle Window.

5. Source Switching:<br\>

• Flexible Encoder allows the system to switch from one Absolute Source to another, should the application determine that it is required.

6. Greater design control of Encoder Pattern:<br\>

• Flexible Encoder allows the application designer greater control over the Encoder Pattern. Such things as number of keys (ex. missing teeth, wide teeth), key strength, teeth to ignore, key tolerance (to allow a key to be detected while allowing for variation due to acceleration), etc can all be designed to meet individual system requirements.

<br\> <br\>

How is a Flexible Encoder System set-up in MotoHawk?

There are many considerations in designing a Flexible Encoder System. We will try to condense the setup here to a few number of steps. Then see the Flexible Encoder Block Help help for additional details.

1. Develop Your Encoder Source Pattern(s) on an xml file and then use the MotoHawk Flexible Encoder Pattern Definition Block to bring the pattern(s) into your model. The Flexible Encoder Additional Pattern Path block can be used to specify the path to the xml files, for the model.

2. Use the MotoHawk Flexible Encoder Absolute Source Block to define the Absolute Sources in your System. An Absolute source is a source that can be used to provide absolute crank angle position. You would have one Absolute Source Definition block for each Absolute source in your system.

3. Define any companion sources (not used to provide absolute crank angle position, ex. camshaft pattern) in the system using the Companion Source Definition Block. 4. Use the MotoHawk Encoder System Definition Block to group a number of Absolute Sources into a System.

5. Use the Flexible Encoder Average Cycle RPM, Cycle RPM Trigger, MotoHawk Average RPM, or MotoHawk Instantaneous RPM blocks to give these calculated values to the control model.

6. Flexible Encoder Get Last Flexible Encoder Source Error can be used to give error information to the control model.

7. If you need to design a variable cam system, there is a Phase Reporting dropdown option on the Absolute or Companion Source selection. Then, the Variable CAM is implemented on Flex Encoder, through the use of the Flexible Encoder Source Phase Trigger and Get Last Source Phase blocks.

<br\> <br\>

Interpolative Triggers

In classic encoder, the TDC would be reported on the next physical tooth. Resolution is one tooth. Flexible Encoder provides for an interpolation between teeth.

See diagram below:

In legacy encoder you need to schedule based on where you see the physical teeth. This can particularly be a problem if there is a low number of teeth. But, with flexible encoder the trigger is interpolative.

On flexible encoder, interpolation resolution is .0625 deg crank angle.

See diagram below:

In legacy encoder you need to schedule based on where you see the physical teeth. This can particularly be a problem if there is a low number of teeth. But, with flexible encoder the trigger is interpolative.

On flexible encoder, interpolation resolution is .0625 deg crank angle.

Average and Cycle RPM

Average RPM

• In Classic Encoder, RPM is defined by the Encoder System's TDC and Missing Teeth contributed to average RPM.
• In Flexible Encoder, the Application Designer controls separately where average RPM is calculated. RPM Sample Points is a vector setting in the Source Definition Block.

Average Cycle RPM

Average Cycle RPM is a new calculation offered with the Flexible Encoder. It can be acceseed with the MotoHawk Flexible Encoder Average Cycle RPM block, and can be used in conjunction with the Flexible Encoder Cycle RPM Trigger Block to read an updated RPM.

In image below, the average RPM is set up to be TDC based.

• Each time encoder sees the next period defined for Average RPM (dark blue, aqua blue, .. green), a new period sum is calculated. When the blue one comes in, fill in the blue. When blue comes in again, blue gets filled in again.

• The Period Sums are added to give Average Cycle RPM.

• A Cycle RPM Trigger executes on each data element

If Cycle RPM is Invalid the Average RPM is Reported (zero speed, some encoder errors such as sync)

It is a FIFO based RPM

How do encoder faults impact Cycle RPM?

It depends on the fault. For a syncronization fault, the Cycle RPM is invalid and the Average RPM will be reported. Other faults, such as Absent Key Fault that do not invalidate position determination would not cause the Cycle RPM to be invalid.

Does Pseudo Encoder support RPM Triggers? No

<br\> <br\><br\>

Absolute and Companion Sources

Absolute Source: An encoder source that may be used by the encoder system to provide crank angle position of the wheel.

Companion Source: An encoder source that it is not used to provide absolute crank angle position. Companion sources are used to help synchronize an absolute source (e.g. tooth synchronizer pattern) and/or provide halfcycle information (e.g. camshaft pattern).

Absolute Source

An Absolute Source is defined in the Flexible Encoder Absolute Source block. An Absolute Source refers to an encoder source that may be used by the encoder system to provide crank synchronous behaviors (like injection) with a high resolution tooth interpolated absolute crank angle position. The actual resolution of the interpolation is dependent upon the number of teeth of the wheel, but in general it will be 0.0625 degrees crank angle.

There are many parameters to set in the Absolute Source Definition Block, so see the Block Help for complete list. Here are a few that may be initially confusing -

Loss Companion

This is the name of the Encoder Source that this source uses to detect loss. This can be another Absolute or Companion Source. Loss is flagged if this source detects a certain number of teeth (set in Teeth Before Loss) on another source.

Synchronization Companions

What is a Synchronization Companion?

Some sources (semi-unique) such as a 36 tooth wheel with 36 equally spaced teeth require a second source to determine absolute crank angle position. A Unique Pattern (ex. 60-2) does not require a Sync Companion, because the position of the wheel can be absolutely determined when the unique key is seen.

A synchronization companion is a companion source that issues a synchronization event to another source when it observes its key. The receiving source uses this key to transform the next [FlexibleEncoderPatternDefinition.html#type_standardsemiunique semi-unique] key that it observes into a unique key. Absolute position can be inferred once the key has been transformed into a unique key.

Some sources may be a Sync Companion, and also give half cycle information - for example a crank wheel with 36 equally spaced teeth and a single tooth cam wheel. In this case, the single tooth cam wheel is specifying which of the 36 crank teeth is being seen, and also what half cycle the system is in. In such a case, the Half Cycle Companion should not be configured for use, as it inherently provides the half cycle information.

For Example: Consider the 3x12M2 pattern in the figure below. Three instances of a missing tooth key are annotated. Each of these instances are the same, which is why the key is said to be semi-unique, and why absolute position of the wheel can't be inferred without a companion. The single key of the 4+1 synchronization companion signals the 3x12M2 source when the key is observed, then the next observed semi-unique key to be marked as unique. A pattern that is to be used for synchronization should have only one standardunique unique key defined so that the system can easily identify what key provides the synchronization event.

Synchronization Window Configuration

The Synchronizaton Window allows ratification of the synchronizing event. The maximum synchronization window annotation describes the worst case window where a synchronization event could occur for this 3x12M2 pattern. The window is measured back from the missing tooth key and has units of teeth. For the 3x12M2 wheel the maximum synchronization window value is 10. No more than 9 teeth should ever be observed between observing the synchronization event and observing the semi-unique key. However, this particular setup happens to have the key event on the synchronizing source (4+1) occurring within the missing tooth region and so the window could be reduced to 0 for this example. Events that fall outside the specified window are ignored.

TDC Synchronization

The absolute source encoder pattern for some encoder systems has semi-unique keys that represent engine TDCs. A 4 tooth encoder (4X) used in a 4-stroke application has one tooth per TDC when in use with an 8 cylinder application. Each tooth is a semi-unique key on such an encoder. Without a synchronization companion the absolute source could guess what key represents TDC#1 since each key is known to be a TDC. The system may just assume that the next observed key represents TDC#1 and force synchronization. The ignition and fuelling system must be capable of allowing the synchronization to be guessed like this and the absolute source must have the same number of keys as there are TDCs else the guess could be wildly incorrect. That is it the engine system must support distributed ignition (or not control ignition), banked fueling (or not control fueling) and have the same number of TDCs as there are semi-unique keys before this approach could be used. The TDCSync tick box enables this option. If the synchronization companion were to be diagnosed as having failed (typically a loss fault), then synchronization would be forced to occur on the first key observed after the failure had been flagged when this attribute is TRUE.

Half Cycle Companion

A Half Cycle Companion is a Companion Source that tells the Encoder System which half cycle the system is in. An example would be a 60-2 crank wheel with Half Cycle Companion being a 4+1 wheel on the cam.

Halfcycle Window Configuration

All sources that utilize a halfcycle companion will need to configure the halfcycle [#halfcyclewindowteeth window]. Incorrect configuration can lead to rogue halfcycle faults.

Halfcycle Window Configuration for HalfCycleEncoding=window

The example above has an arbitrary crank key defined that identifies tooth #1 on the crank wheel. The cam tooth is an edge key (every observed tooth of an edge key is considered to be a key) and as such needs to be looked for in a window. The pattern's HalfcycleEncoding would have been configured for window. The halfcycle window occurs between crank tooth #13 and crank tooth#1. If at least 5 crank teeth have been observed prior to observing the crank key then the encoder source can infer that the cam tooth would have occurred if it was going to occur. Note that the crankshaft revolves twice for one camshaft revolution and so every second key will occur without the cam tooth occurring. The encoder source thus infers the halfcycle by looking for the presence or absence of the cam tooth within this window. Configure the window to be too small and the encoder will look in the wrong region and incorrectly assume the halfcycle state that is applicable when the cam tooth is not observed. Configure the window too large and the encoder startup performance is compromised because all the window teeth need to be observed before halfcycle determination can occur.

An encoder that needs to use a companion that is employing HalfcycleEncoding=window should only have a single unique key defined. To define more will confuse the implementation because it does not associate the window to a specific key.

Halfcycle Window Configuration for HalfCycleEncoding=state

The halfcycle [#halfcyclewindowteeth window] is still important for start-up performance. Here the window defines how many source teeth on the crank (normally) need to be observed before the source can assume that the halfcycle companion will have synchronized. The window is always measured relative to the worst case key location. The figure [FlexibleEncoderPatternDefinition.html#FlexiEnc_XML_HalfCycleEncoding here] illustrates.

Companion Sources

Companion Source is also an encoder source except that it is not used to provide absolute crank angle position. Companion sources are used to help synchronize an absolute source (e.g. tooth synchronizer pattern) and/or provide halfcycle information (e.g. camshaft pattern). There is often fewer resources required by a companion only source compared to the resources needed by an Absolute Source and so more module resources can usually support such inputs.

A Companion Source is Defined by the MotoHawk Flexible Encoder Companion Source Definition Block.

Loss Companion

A Companion Source will always have a loss companion, because a companion source will never exist in design without at least one absolute source. Loss is flagged if this source detects a certain number of teeth on the referenced source.

Key Event Aligns With Companion Source

The Key Event Aligns with Companion Source tick box is used to signal that a key event occurs in the vicinity of a companion key event. This is most commonly used by a tooth cam or synchronizing source that has an edge that occurs in the vicinity of a crank tooth. When the key event occurs near a tooth there is a risk that system variations will see the key event from the source associated with different teeth on the crank. This will lead to unexpected operation.

Consider a 36 tooth crank shaft encoder that uses a single tooth companion to provide synchronization. If the synchronization tooth occurs in the vicinity of a crank tooth then there is a chance that the synchronizer tooth may occur before or after that crank tooth. This would mean that the key event will be associated with different crank teeth, yet the intention would be to want to always associate this tooth with the same crank tooth. In this situation the [#keyeventalignswithcompanionsource Key Event Aligns with Source] would be set to true. If it occurred more toward the middle of the crank teeth then it would be set to false.

Whilst a tooth companion was used as an example, this attribute could also be used for a 6+1 companion that was providing a synchronizing event to a crank encoder that had 36 equidistant teeth.

Phase Error Examples

Source Switching

In Flexible Encoder the Application can switch from one source to another and that switching is handled automatically.

The classic encoder does not allow for source switching

For example, if the application detects that the crank signal is broken, the application can switch to the cam encoder or another source. Both sources are defined as absolute sources, and the system is set up to define 'loss companion'.

Switching the Active Source is a Decision of the Application Designer

The overall System is Defined in the Flexible Encoder System Definition Block, shown below. All system sources are listed in this block and

Pseudo Encoder is just a different source

Source

This unsigned integer signal input port defines what source the model wants to be the active source. The value will correspond to the Crank Position Source instance or be zero if the pseudo encoder is to be requested.

In the System Definition block above, if you put a '1' in the Source input port, you would use Source 1: CnkEncoder. You could define source 2, source 3 etc. If you put a '5' into Source input port and there wasn't a Source 5, you would get an error from the Active Source output of the block.

The Enable input to the Pseudo Encoder shown below is ignored, pseudo encoder must be defined as any other source in the system.

Active Source This signed integer outport signal defines what source is currently considered to be the active source. The value will correspond to the Crank Position Source instance that is considered to be the active source, or to zero when the pseudo encoder is in use, or a negative number of no source is active. An encoder system without an active source can't detect crank angle position and thus prevents the support of crank synchronous behaviors.

When to Switch

The encoder system will likely want to switch encoder sources when it supports redundancy and the active source is issuing faults. While the application model ultimately controls what Absolute Source the encoder system will use for its crank synchronous behaviors, when to switch should be considered based upon the desired performance.

For example, observing a Loss Fault will nearly always result in switching to an alternate source. A Synchronization Fault may also constitute a need to switch because the signal should never result in synchronization faults if it is operating correctly. However a Halfcycle Fault or an Inversion Fault may not force a switch. A Halfcycle Fault can result because of setup problems and/or because of problems with the companion sensor. The inversion fault implies a setup problem.

Consequences of Switching

The encoder system aims to make a switch between encoder sources as seemless as possible, but it is not instantaneous.

A switch will result in all crank synchronous pulses (like injection and ignition) terminating before the switch is made. The effective encoder relative timings will need to change when the source is switched and consequently the existing timings can't be trusted. Therefore the pulses must be turned off. Furthermore the internal tracking system must achieve a lock with the new encoder source. A lock can only be achieved after two teeth have been observed by the new active encoder source. Consequently there will be a delay between applying the switch and that new source allowing crank synchronous pulse generation to occur.

<br\> <br\> <br\>

Time Delay Before Attempting Sync

Some Source Switching Considerations

Does the application allow failover switching while running?

Does it allow failover switch only as a pre-curser to cranking?

How does the application handle an 'absent key' fault?

How are sensor faults on the active source used to drive source switching?

Loss Fault on the active absolute source would cause a switch.

Repeated 'synchronization' type faults could cause a switch

Application must decide... how many faults? what type of faults?

There should be no faults on the source that is switched to. <br\> <br\>

Diagnostics

Fault Data for the Flexible Encoder is reported to the Application using the Get Last Flexible Encoder Source Error block.

The user references the block to either an Absolute or a Companion Source, and the fault value for that source is given on the Error Outport.

Available Faults

Synchronization Fault (value=1)

A source suffers a synchronization fault when the tracked position does not match the calculated position. Tracked position is updated each time a source tooth is observed. Calculated position is updated each time a [FlexibleEncoderPatternDefinition.html#type_standardunique standard unique] key is observed. It is checked once updated and this fault is issued when the two don't match and the source has previously achieved synchronization. The tracked position is not valid until the first calculated position has been observed and so synchronization faults are not possible until this first key match has occurred. This is important to note because the system may never achieve an initial synchronization if the key setup is wrong.

Halfcycle Fault (value=7)

A halfcycle fault is observed when the tracked position does not match the calculated position, but a [#syncfault Synchronization Fault] has not been observed. It implies that the system has a problem with the halfcycle determination, which could be due to companion sensor setup.

Loss Fault (value=2)

A loss fault occurs when sufficient teeth have been observed on a companion sensor without having observed any teeth on the sensor under test. See [FlexibleEncoderCompanionSource.html#teethbeforeloss Teeth Before Loss] configuration. A loss fault can only be detected when a companion sensor exists because the system requires an alternate source of rotation detection to detect sensor loss.

Inversion Fault (value=3)

An inversion fault requires a specialized [FlexibleEncoderPatternDefinition.html#type_signalinverted inverted] key to be specified. It is used to attempt to detect an inverted signal connection.

Phase Fault (value=4)

Issued when one source is not within the specified phase of another. A source is said to have suffered a phase error if its zero tooth (as defined by the [FlexibleEncoderPatternDefinition.html#XML_PhysicalTeeth Pattern Definition Physical Teeth] entry of this source's referenced pattern) falls outside the window defined by [FlexibleEncoderCompanionSource.html#startphasewindow Start Phase Window] and [FlexibleEncoderCompanionSource.html#endphasewindow End Phase Window]. See [FlexibleEncoderCompanionSource.html#FlexiEnc_PhaseError example figures] that illustrate this error.

Absent Key (value=5)

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. Configured by the [FlexibleEncoderPatternDefinition.html#XML_TeethBeforeAbsentKeyFault pattern] in use by the named source.

Reverse Rotation (value=6)

Reserved for future support.

Bad Halfcycle Window (value=8)

This errror is only observed when halfcycle [FlexibleEncoderPatternDefinition.html#XML_HalfCycleEncoding window] encoding is in use. Consecutive occurrences of this error suggests that the halfcycle window has not been correctly configured. It occurs when halfcycle events are being observed, yet none of these events are being observed within the window. Consider a tooth cam in a crank/cam system. This error would be flagged if, say, the tooth cam event was occurring 10 teeth before the crank's key, yet the window was only set to 8.

How is a Flexible Encoder System set-up in MotoHawk?

There are many considerations in designing a Flexible Encoder System. We will try to condense the setup here to a few number of steps. Then see the Flexible Encoder Block Help help for additional details.

1. Develop Your Encoder Source Pattern(s) on an xml file and then use the MotoHawk Flexible Encoder Pattern Definition Block to bring the pattern(s) into your model. The Flexible Encoder Additional Pattern Path block can be used to specify the path to the xml files, for the model.

2. Use the MotoHawk Flexible Encoder Absolute Source Block to define the Absolute Sources in your System. An Absolute source is a source that can be used to provide absolute crank angle position. You would have one Absolute Source Definition block for each Absolute source in your system.

3. Define any companion sources (not used to provide absolute crank angle position, ex. camshaft pattern) in the system using the Companion Source Definition Block. 4. Use the MotoHawk Encoder System Definition Block to group a number of Absolute Sources into a System.

5. Use the Flexible Encoder Average Cycle RPM, Cycle RPM Trigger, MotoHawk Average RPM, or MotoHawk Instantaneous RPM blocks to give these calculated values to the control model.

6. Flexible Encoder Get Last Flexible Encoder Source Error can be used to give error information to the control model.

7. If you need to design a variable cam system, there is a Phase Reporting dropdown option on the Absolute or Companion Source selection. Then, the Variable CAM is implemented on Flex Encoder, through the use of the Flexible Encoder Source Phase Trigger and Get Last Source Phase blocks.

Pattern Construction

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.

Overview

A Flexible Encoder XML encoder pattern definition must contains the following nodes within an < Encoder > node (unless the node is marked as optional):

• Name - Optional
• DescriptiveName
• PhysicalTeeth
• Keys
• TeethBeforeAbsentKeyFault
• DefaultKeyTolerance
• ClrHalfCycleTooth
• SetHalfCycleTooth
• HalfCycleEncoding
• EquidistantToothDisplacement_deg

Name

Name is typically matched to the file name and is optional.

Descriptive Name

The first step is to give the pattern a descriptive name. The DescriptiveName identifies this encoder pattern definition to MotoHawk. This name should be unique for all the encoder patterns supported by a model. You can name the pattern whatever you want, but the way MotoHawk associates the pattern is the Descriptive Name. In the below example, this is custom18M1.

Hint: Put 'custom' in front of the pattern, so you won't have a name clash with any patterns predefined in MotoHawk.

Physical Teeth

Define the Physical Teeth for your pattern. 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.

Start at 0. You must define tooth 0, and you must start at tooth zero.

Define each tooth, relative to tooth zero.

Don't Include Missing Teeth.

Start where most equidistant teeth are for best compression

Name

Name is the tooth name and by convention is a number that starts at zero and increments with each definition.

LogicalDeg

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.

<br\> <br\>

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 and EndDeg

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.

Equidistant Tooth Displacement Degrees

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. It can be approximate. Round up. For 60-tooth wheel, the value is shown below as 6.

Key Construction

<br\> Keys Describe how to synchronize a pattern and are identified by the application developer. <br\> <br\>

A key is a pattern that is used by the flexible encoder system to facilitate 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.

Keys are Constructed from RATIOS.

• A ratio is used in the construction of a KeyValue
• A sequence of Ratios forms a detectable pattern

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) as shown on the 8 minus 1 wheel below. The missing tooth provides a synchronization marker because it uniquely identifies a point on the wheel. Tooth Period is shown as Tw, Tx, Ty, and Tz below.

The following patterns can be seen:

The ratio of angle displacements just before and after the missing tooth will be 1.0, 2.0 and 0.5.

• Neighboring 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,
• 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. It could search as well for a 1, followed by a 2, followed by a 0.5.

DefaultKeyTolerance allows constant speed of rotation to be assumed by installing a window of acceptable ratio values, to provide tolerance for acceleration.

Combining ratios can increase the strength of the key.

NNote 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.

A pattern may support more than one Key and there are also different types of keys.

Key

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 under the section titled 'ratio'. ToothPosition is optional/meaningless if the type is not a standard key.

Types of Keys

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 [FlexibleEncoderAbsoluteSource.html#synccompaniondetail 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 [GetLastFlexibleEncoderSourceError.html#FlexiEnc_SignalInversion 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).

Standard Unique Keys

Standard: Provide Sync <br\> Unique - Stands Alone <br\>

The 18M1, 60M2, 36P1 would all be examples of Standard Unique Keys.

Standard Unique is something you would use for something like 18M1, 60M2,4P1.

Standard Semi-Unique Keys

Standard: Provide Sync Semi-Unique - more than one

Example: There are three sets of missing teeth pairs. There is a key at missing tooth regions, but if encoder detects the key it doesn't know where it is.

SEMI-Unique: The same key but more than one.

height<br\> You could also throw the other keys out when you are defining the pattern based on physical teeth, and then only use one key.

Edge 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 CamTooth below or a 36 equidistant tooth wheel would utilize such keys.

Companion Support

A tooth cam like the example CamTooth below is an example of an edge key, that is being used as as a companion support key.

If the pattern was 36 equidistant teeth, it would be providing positional information so would be standard-semi unique, rather than companion support as shown in xml file above.

Tooth

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.

This is the Sync Point:

Ratio

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).

Pulsewidth or ToothPeriod? Either the period between the tooth edges or the width of the teeth can 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.

ToothPeriod: 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.

The 18M1 Wheel shown below is based on Period of each tooth in the sequence. So, equidistant teeth gives 1, gap gives 2, then next tooth/gap gives 0.5 for Tooth Period.

PulseWidth: The width of a tooth can also be used for pattern detection, for example on some digital type patterns that don't have extra teeth or missing teeth, they change the width of a tooth or some teeth. . 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.

Key Ratio resolves to .0625 degrees, it is a 4 bit fixed point value. So if you set ratio to 2.7, it would be rounded. Also, Ratio cannot be larger than 15.

Teeth Before Absent Key Fault

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.

Default Key Tolerance

Defines the Plus or Minus window that is applied to each ratio value to create an acceptable key range. The value saturates to zero or to a maximum. The wheel will be accelerating, even at a constant speed the pistons are firing, so there will be some localized accelerations if you look at Instantaneous RPM. This gives a tolerance on the Key Ratio to account for accelerations.

Choose a value that will still allow normal teeth to be rejected as keys, while allowing for acceleration.

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.

Remember, resolution is 0.0625.<br\>

When you are developing a pattern on the bench, test at all ranges of your RPM with Margin. <br\> <br\> <br\>

Half Cycle Source Attibutes

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). Pattern Half Cycle State attribute exists on all patterns that you define, but may not be applicable to all patterns but you still have to define the values.

All pattern definitions shall must have the following attributes:

• HalfCycleEncoding
• ClrHalfCycleTooth
• SetHalfCycleTooth

HalfCycleEncoding

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.

ClrHalfCycleTooth

The half cycle is represented as a Boolean value - either cycle 0 or cycle 1. The Encoder does not care which half cycle is which, only that they are defined. Calibration of TDC offset gives half cycle position for the system.

The ClrHalfCycleTooth clears the halfcycle Boolean when this cycle is observed.

Half Cycle 0 <br\> <br\>

SetHalfCycleTooth

This attribute sets the halfcycle Boolean when this tooth is observed.

Half Cycle 1

Example: In the example below, inside ring when tooth zero is detected then Half Cycle State is Blue (0). When Tooth Two is seen, then Half Cycle State is Yellow (1).

This can also be defined as on the outer ring, for tooth 1 and 3.

"Is one definition better?' In this case, yes. There are two factors here: 1. Half Cycle State is queried when the crank's missing tooth is detected. 2. In order to detect sensor loss, teeth on the other sensor must be seen.

If the cam sensor is lost, the second setup is better because there is more opportunity to detect the missing cam.

Frequently Asked Questions (FAQ)

1. Can Woodward add Flexible Encoder Support for the 128 pin module?

No, the TPU on the 5xx modules (48, 80, 128-pin) aren’t capable of supporting as complex and flexible as the Flexible Encoder (5xxx modules have an eTPU, or enhanced TPU). <br\>

2. How do I define my sensor type (Vr or Hall Effect)?

There is now a new block, Interface (VR/DG) under Module Configuration Blocks library of MotoHawk. If you don't put a signal interface block in your model, you will get a build warning. <br\>

3. Can I use an old version of MotoHawk?

No, 2012a or higher is required for Flexible Encoder. <br\>

4. Does Flexible Encoder support Variable CAM?

Yes, there is a Phase Reporting dropdown option on the Absolute or Companion Source selection. Then, the Variable CAM is implemented on Flex Encoder, through: Source Phase Trigger, Setting the "Phase Reporting" attribute on the source to a suitable value, Get Last Source Phase block. <br\>

5. For a CAM-only pattern, such as 6-Plus-1, should it still be defined as if it were 360-degrees?

Yes, the xml pattern defines a WHEEL, so it must be 360-degrees. <br\>

6. Are there any example xml files?

There are some xml patterns included with MotoHawk as examples in the MotoHawk installation. /Motocoder/Encoders (ex. C:\Program Files (x86)\Woodward\MCS\MotoHawk\2012b_beta4.298\MotoCoder\Encoders). <br\>

7. When defining a CAM pattern, should I start with tooth 0 at angle 0, or should this contemplate the phase difference between the two wheels?

When defining the XML file, define it for the wheel 360-degree pattern whether it is for a cam or crank wheel with tooth 0 at angle 0. This just describes the pattern. Then, the phase relationship(s) are defined in the Absolute Source block and the Companion Source blocks.

An example could be the same pattern definition can be used twice yet have different phasing. E.g. single 60M2 wheel with two sensors <br\>

8. Can you confirm that both the 60-Minus-2 and 6-Plus-1 patterns would be considered standard unique and that rather than a Sync Companion, the 6-Plus-1 should be setup as a Half-Cycle Companion?

The two terms are being mixed here. But, yes as long as the two missing teeth are not on direct opposite sides of the 60-2 wheel, the 60-2 and 6+1 patterns would be Standard Unique.

Standard Unique

60-1 or 6+1 pattern would be considered Standard Unique, meaning that when you see the key you would know exactly where on the 360-degree physical wheel rotation you are. For 60-2, if the two missing teeth were located together then this would be Standard Unique. If the two missing teeth were on each side of the wheel, equidistant with 29 equidistant teeth between, this would be Standard Semi-Unique as you don’t know exact position on the physical wheel when a missing tooth is seen, i.e. which missing tooth is it? Standard means it can be used for synch, unique means it stands alone.

For a Semi-Unique source you need another source to determine position on the actual wheel, for synching. This is the Synch Companion.

Even if you have a Standard Unique pattern, you would need another (companion) source to determine half cycle information. A companion source can give half cycle information (ex. CAM). A different absolute source can be used as a companion also, and this could provide redundancy. So, a 60-1 and a 24-1 would both be defined as Standard Unique sources, and in one application the 24-1 could be a companion to the 60-1 and provide redundancy in the event that the 60-1 is lost. In another application the 24-1 could be the absolute source with a different (maybe single tooth) wheel as a companion. <br\>

9. For a 60-1 on crank, 6+ 1 on cam, so Source1: CrkEncoder Source2:CamEncoder. Should they both be set up as an Absolute Source, or should the CAM be a Companion source?

Setting them both up as an Absolute source provides a limp home capability provided the source is added to the System Definition block, so it can be switched to. Setting up the CAM as a Companion Source instead is less resource intensive (eTPU, RAM, ...) so if your system was really constrained, then you might discard limphome to free up resources. If the 6P1 were a variable cam phaser, then specifying it as an Absolute source would not serve a purpose.

10. Is there a penatly for using too many keys?

Yes, the system would need to look for each key so this would impact execution time, resulting in syncronization errors. When you are developing a pattern on the bench, test at all ranges of your RPM with Margin

11. When defining the teeth in the xml file, do I have to start tooth zero where there are the most equidistant teeth? The pattern must be stored in the eTPU. You can define the pattern any way you want to, but starting where there are most equidistant teeth saves eTPU space.

12. Should I define a CAM pattern as 360-degrees or 720-degrees? Cam wheels are still defined based on 360-degrees. It is a wheel, so always 360-degrees.

13. What happens if, due to an issue with the encoder wheel, an extra tooth is detected or a tooth is missed? Once initially synchronized, pulses are scheduled on the assumption that the teeth correspond to the defined pattern. The failure to detect a tooth would make al pulses scheduled between that missed tooth and the key to be late. Similarly, detection of an extra tooth would result in pulses that would occur earlier than expected. The average and instantaneous RPM calculations at the point of the erroneous missing or extra tooth would be incorrect. The system would recover once the real key is seen. The encoder state would not change; it would continue to report synchronized. However, a synchronization error would be flagged when the key is detected, since the tracked position would not equate to the calculated position defined by the key.