Baffled by Prop-2 Quadrature Encoder
JonTitus
Posts: 193
I have tried to write a short assembly-language program to collect a quadrature-encoder count over 2 seconds as an example to help update the Smart-Pin documentation. I have LEDs on eight pins as a testing device:
Obviously I have not set up the pins properly and don't know how to. I have a P2 EVAL board. Pin P32 receives one encoder output, P33 receives the other. The encoder's common connection goes to EVAL ground. The encoder is fine. I can see the proper signals when operated as a stand-alone device. The P32 and P33 connections have external 1K-ohm pullup resistors. I have used a scope to monitor the P32 and P33 signals (see attached image.) When I start the program and rotate the shaft, I can see the proper pulses on the P33 input. The P32 input, though, drops to a logic-0 at the proper time, but it stays at logic 0 for as long as the program runs. If I take another scope image as the program continues to run, P32 remains "locked" at logic 0.
Feel free to offer a different simple program or to modify mine. All assembly language, please. Thank you. --Jon
'Example Quadrature Encoder Rev. 1. 05-30-2020
COM
dat
org 0
mov dira, ##$FF 'Set P15..P8 as outputs for LEDs
mov outa, ##$AA 'test pattern for 8 LEDs, they light properly
dirl #32 'Setup Smart-Pin at P32
wrpin QuadEnc_Config, #32 'Set configuration for Quad-Encoder mode
wxpin X_RegData, #32 'Set operating condition for period
dirh #32 'Finished setup
nop 'short delay
nop
.myloop nop
.wait_here testp #32 WC 'Test carry at Smart-Pin P32
nop
if_nc jmp #.wait_here 'No carry? Loop
rqpin QuadEnc_data, #32 'Get total counts
nop
mov outa, QuadEnc_data 'send to LEDs
jmp #.myloop 'Program waits forever
QuadEnc_Config long %0000_0001_000_00010_00000000_01_01011_0 'Quad encoder mode, sets B as pin 32+1 (33)
X_RegData long $02FA_F080 'Set 2-sec sample period (25 MHz clock)
QuadEnc_data long $0
Obviously I have not set up the pins properly and don't know how to. I have a P2 EVAL board. Pin P32 receives one encoder output, P33 receives the other. The encoder's common connection goes to EVAL ground. The encoder is fine. I can see the proper signals when operated as a stand-alone device. The P32 and P33 connections have external 1K-ohm pullup resistors. I have used a scope to monitor the P32 and P33 signals (see attached image.) When I start the program and rotate the shaft, I can see the proper pulses on the P33 input. The P32 input, though, drops to a logic-0 at the proper time, but it stays at logic 0 for as long as the program runs. If I take another scope image as the program continues to run, P32 remains "locked" at logic 0.
Feel free to offer a different simple program or to modify mine. All assembly language, please. Thank you. --Jon
Comments
Remove the %01 from the %TT bits
Dealing with it in code: If it's an encoder that delivers four counts per detent, setting mod4x to 2 will fix things so that each "click" gives a single count (mod4x is 0 otherwise).
Where is the accumulator and how do programs access it?
The accumulator is internal to the smartpin. Z gets a direct copy if X = 0, otherwise Z gets the delta of the accumulator for the prior X period.
I understand the Z=0 case for continuous tracking. But I still don't understand the accumulator. In the statement from the documentation, when X is set for a period, say 2 seconds, at the end of that period, Z holds the count result. How can Z also hold the +1 / 0 / -1 information for any transitions that need to get added to the count? How do I get the +1 / 0 / -1 information?
If someone didn't want the two LSBs of the encoder count, they could just divide by 4 or do a "SAR reg,#2".
That a just complicated way of describing the details of P2's ability to do Capture-and-clear on the counters, in a lossless manner.
If you do design Capture-and-Clear, there is an aperture that needs manage, of what happens if on the same SysCLK, the counter is being asked to clear and inc/dec ? (rare, but possible)
In that case, you need to not clear to 0, but to include the count (+1, -1) that would have occurred on that SysCLK.
You do not need to read that clear value, it is just there, as a correct residual & ready for the next capture.
All this means you can sample a frequency counter at 10x a second for rapid updates, and run another 10s or 100s background average, that you know has no missed edges.
In a quad context, you could run two smart pin cells, one as a Quad total displacement, and another for velocity.
Or, you can continually sum those velocity captures (every X) and get both velocity and displacement with a little SW, and just a single smart pin cell.
When doing that continual sum in SW, it is important to know you never miss a single quadrature edge event.
Thanks, JMG, that description works... unless you don't know what "capture-and-clear" means. I try to keep explanations easy to understand for people new to the Propeller. These explanations might seem wordy to experts, but I hope they help beginners--like me. --Jon
Most MCUs have a capture ability on their counters, even 8 bit ones. That takes a snapshot of the HW value, for later inspection by slower SW.
A small subset of MCUs can optionally clear the counter when they capture.
If there is no clear, the user can take a difference in software, to determine change since last capture.
The P2 has that capture-and-clear feature, done in a careful way.
So if the current position is lost and the device needs to run to a home point with whatever end stop it usually crawls along with low velocity to avoid damage at the mechanical(?) endpoint?
Shouldn't it be possible to get some ruff estimate of the current position (say I am in the 3 eights of available distance) with some second simple encoder or even switches?
Thus at least running some of the distance at full velocity?
just asking...
Mike
The encoder index, if used at all, is searched for after the home sensor is found. This will normally be a very short distance and the motion can be slow and still hardly noticed.
If using just the home sensor as the reference then a slow return motion back off the home sensor can be used instead of searching for an encoder index.
PS: An end-of-travel sensor can double up as the home position.
Quad counters are simpler, but power failure means you are never sure where you are...
Another factor maybe obstacles. In the case of CNC equipment the machine doesn't know anything about the materials that might still be loaded when doing initial referencing. Extra slow movement gives time for the operator to intervene before tooling gets broken.
The common strategy is to always lift the vertical axis first to retract the tool out of the workpiece. This avoids collisions in almost all cases. Only if you use a T-slot cutter or a tap you have bad luck...
If you don't have absolute encoders you could use a low-cost switch that is ideally mounted half a screw revolution before the index pulse of the encoder. You can do the first aproach move with relatively high speed. You just need to make sure that the distance from the switch trigger point to the hard stop is longer than the braking distance.
You can include something like this in your loop: That provides a capture where the last index impulse was detected. When the servo comes to a halt after the home switch search you can read the indexPos variable and there are 3 possible cases:
Lots of possibilities.