Incremental Encoder -> Quadrature Encoder Counter

Question

Dear plexim team

For the operation of my PMSM I would like to use an encoder.
In a first step the PLECS block "Incremental Encoder" should emulate the used HW-Encoder. 

Data sheet HW-Encoder

• Signals: Phase A, Phase B, Index I
• Resolution in pulses per revolution: 1000

PLECS block Incremental Encoder Settings

• Encoder module: Encoder 1
• Digital output channels (A,B,I): [8,9,10]
• Line pairs: 1000
• Coding in forward direction: B follows A
• Angle calculation: Extrapolation

1. Question 1: Have I set "Line pairs" correctly? Does Line pairs correspond to "Resolution in pulses per revolution"?

In a second step, the PLECS block "Quadrature Encoder Counter" should evaluate the "Incremental Encoder" generated signals.

1. Question 2: If I insert the PLECS block "Quadrature Encoder Counter" in the controller the following input signals top scheme result:
   - Counter1/s [2-Dimensional]
   - Counter1/omega
   - Counter1/theta
   What do the input signals Counter1/theta, Counter1/omega and Counter1/s mean and how are they to be used together with the "Incremental Encoder" which provides the signals Phase A, Phase B and Index I, so that the speed and the angle of the rotor is calculated?
   PS: A minimal example would be very helpful.

For these two questions I refer to my minimal example in the appendix. I use the following versions:
PLECS Standalone: 4.4.3
PLECS RT Box: 1.8

Thank you for taking the time to answer my question.

Best regards
Raphael

Answer 1

Raphael,

Thank you for clearly describing your questions and modeling challenges.

Question 1: Have I set "Line pairs" correctly? Does Line pairs correspond to "Resolution in pulses per revolution"?

The help menu for the coder defines the Line Pairs parameter as follows:

"Defines the amount of pairs of black and white lines and therefore the encoder resolution. For every line pair, 4 state transitions at A, B per revolution can be seen. The index pulse at I is set once per revolution when the angle crosses 0." 

Generally, the definition agrees with the pulses per revolution from encoder vendors, and 1000 would be the appropriate value, but I would double check the vendor documentation to confirm.

Question 2: If I insert the PLECS block "Quadrature Encoder Counter" in the controller the following input signals top scheme...

Currently the two blocks are not IO compatible.  There is an effort to resolve this in a forthcoming TSP release.

An interim workaround is to break the library link of the Incremental Encoder and change the offline implementation.  You can do this by right clicking the component and selecting "Subsystem + Break link" and then "Subsystem + Unprotect".  Then with a bit of copy/pasting you can wire the speed and angle inputs as output signals for the parent subsystem. The Quadrature Encoder Counter accepts angle and speed  inputs in radians and rads/sec. You would need to add a bit more logic to have the direction and index pulse logic for the "s" output of the Quadrature Encoder Counter perform similar to the RT Box.

The code deployed to the RT Box would not be impacted by changes in the offline model.

Regards,

Bryan

Comments

Thanks Bryan for your detailed answer that has already helped me a lot.

I would like to comment on your solution to question 2. Basically, I don't want to change the Incremental Encoder block, because it is supposed to represent my real encoder. This means that the incremental encoder should provide exactly those signals that are also expected from a real encoder. So the following signals:

• Phase A, Phase B and Index I.

What I want to achieve is that the Quadrature Encoder Counter reads these signals and processes them accordingly. As I understand it, it doesn't work at the moment. For this reason I will probably have to create my own evaluation system, which on the one hand counts the edges of both phases and on the other hand measures the phase shift between them. The speed and the angle can then be calculated from this. What do you think of my approach.

Best regards, Raphael

---

Glad to hear my response was helpful. In many instances modeling the pulse train as it would appear in hardware is not significant because only the count, speed, and status signals are what would be returned from querying the hardware.  Therefore you could derive a model that would be fairly representative of how the RT Box would perform with the approach mentioned in my answer.

That being said, if you would like to count the pulses for a specific reason, say to model what a different piece of hardware would return, a good place to start would be reviewing the TI C2000 Target Support Package Quadrature Encoder implementation.  In that model the pulse train is decoded.

Good luck!

---

Good morning Bryan
Thanks for your feedback. Do you think it is possible to read and evaluate the three signals phase A, B and index I with a analog in block? Is this block fast enough to detect at least 1000 pulses per revolution? At maximum speed (2300 rpm) this would mean that a time of 26.09us would pass between two pulses.
Greeting, Raphael

---

The suggestions above pertain mostly to the offline model, so it is not clear to me why for real-time simulation with the RT Box you would not use the provided Quadrature Encoder Counter. It is the most straightforward option. Is there a particular reason why it doesn't meet your needs?

Also, I believe the timing you suggested is off by a factor of 4x due to the quadrature relationship of the A & B signals. Also, in many encoders the index pulse is only active for 1/4 of an overall cycle (e.g. only while A high and B high), so you might miss an index pulse if the discretization step size over 6.5 usec.

---

You are right, adapting the existing quadrature encoder counter is probably the most sensible option. I have now been able to implement that.

Now I have to use analog inputs instead of digital inputs, because the signal levels from the real encoder are defined as follows:

• High_enc = 0.4V, Low_enc = -3V 

If these signals were read in with a digital input, they would be misinterpreted because:

• High_dig> 2V, Low_dig <0.8V

For this reason I need analog inputs.

• How can I change the Quadrature Encoder Counter in the block so that the analog inputs are effectively reserved for my signals? 
• Do I need the Require () function for this? 
• If so, where is this function documented?

For a better understanding, I have attached two pictures:

• Input settings from the quadrature encoder counter block 
• Code from the quadrature encoder counter block

Thank you for your time.

Greeting, Raphael

---

The incremental encoder functionality is inherently linked to the digital IO of the RT Box hardware.  The approach of modifying the encoder block to use an analog input as you are suggesting will not work.  You would have to use the Analog In block and decode the signals using standard PLECS blocks. Again, this approach is not really recommended due to limited time resolution.

This conversation is starting to be more appropriate for one-on-one support.  Please reach out to support@plexim.com with your questions.

I also note that the output voltage levels sound strange.  Any chance some of your polarities are reversed? In your email to support, please include the exact encoder hardware you are using.