homing & encoders

I'm very happy to see this scope trace - everything is doing what it's been told to.

gtom wrote:

Encoder, Stepgen cmd & stepgen fb run fine.
Then the Index is tripped, encoder sets its Value to 0
-> Position- feedback remains untouched (as desired)
-> Position-cmd changes by the difference of the motor-position / new position

Why does the cmd position "jump"? Is this a bug outside stepgen???

You have your system configured to use stepgen as the motion effector, and encoder.position as the position feedback.

When you home, the machine finds its limit switch, then the encoder finds its index. At that point the machine is home, and its position is supposed to be zero. The encoder correctly resets its position to zero, and the higher-level trajectory planner correctly resets its commanded position to zero. The trajectory planner's position command is connected to the stepgen's position command so that the stepgen goes where the trajectory planner tells it. This is why stepgen.position-cmd gets a zero when the machine finds its home, this is intentional.

in the middle section you can see where the motor "runs away".

The motor does not run away: stepgen.position-fb moves smoothly in your scope trace, honoring accel and vel limits.

gtom wrote:

Hi Seb, following a Scope where i set FMIN_ERROR to 10 (then the homing on index works!)
Is the difference between cmd and fb normal???

On an incorrectly set up machine like yours, that difference between stepgen.position-cmd and stepgen.position-fb is to be expected - it's a symptom of the configuration error you have.

You have two things mechanically connected together: the encoder and the stepgen. Each of those things has a different idea of what the current position is, and each is telling you where it thinks you are.

There are two feedback loops active. For the feedback loop in emc2, the homing logic provides the command, the encoder's position is the feedback, and the stepgen's command is the output. For the feedback loop internal to the stepgen, emc2 provides the command, stepgen's position is the feedback, and the step rate sent to the FPGA on the 5i20 is the output.

That's your setup (as i understand it), now, back to the scope trace above.

When you tell emc2 to home, emc2 tells the stepgen to move towards the home switch. As the stepgen moves, both the stepgen position feedback and the encoder position feedback change together and agree, and things work reasonably well. But when the encoder hits the home switch and gets its index signal, the encoder position feedback resets to zero, and the stepgen's position feedback does not. This is the ultimate cause of your problem.

emc2, thinking that the joint is now homed, immediately resets the stepgen's position-cmd to zero, which is equal to emc2's new position feedback (from the encoder). emc2 intends this to mean "you should stop and stay where you are now (zero), because you are now homed". But inside stepgen, position-fb has not been reset to zero. So stepgen thinks, "oh no, i'm at 5 (or wherever it happens to be), but my command says I should be at zero, i better get moving!". It outputs a step rate to the FPGA to start moving towards its command (zero). As the stepper starts turning, the encoder reports that its position is changing. emc2 notices, and starts changing the stepgen's command to counteract (what is to emc2) the un-commanded move.

There are some other things affecting the situation: stepgen tries to match both the velocity and position of its command, and there is strange feedback between the stepgens command-seeking algorithm and the mechanical coupling between stepgen and encoder. It's a strange, broken system.

You need to fix the problem described above. I'm probably not the guy to tell you how your machine should be configured, but here are a couple of suggestions anyway.

1. Try detecting the index pulse and reset the stepgen position to zero. There's currently no stepgen pin that performs this reset (in either the software or the hm2 stepgen), you'd have to rig up a pair of adders in HAL, one between the position command coming out of emc2 and the position-cmd going in to stepgen, and the other between the position-fb coming out of stepgen and going in to emc2.

2. Try running the stepgen in velocity mode (this was added recently at Fest, it's available in Trunk and the 2.3 branch in CVS, and will be in the 2.3.2 release). In velocity mode, stepgen doesnt care about its position-fb. You'd use a PID loop with the position command being the command from emc2, the feedback being the encoder position, and the output being the stepgen velocity. This essentially turns your stepper into a servo.

3. Ask someone who knows what they're talking about, not a dodgy hack like me.

gtom wrote:

Please correct me if im wrong:

If i add an pin to the encoder that provides a "reset" signal it would be easy to connect this signal to the stepgen- reset (as mentioned above). At the moment when the index is hit emc sets the pos-cmd to 0.00 and the encoder sets its "reset" pin. This pin can be connected thru hal to the stepgen reset and sets the internal stepgen counter to 0. Now we should have the "right" condition : Feedback & cmd Positions are the same and the encoder & stepgen are "synchronized"....

Thomas

Hi Thomas,

the only assumption you are making is that the reset and the index are happening in the current servo-thread execution.
In praxis the index reset of the encoder counter (not the software encoder counter, but the encoder counter in HM2) is happening in the FPGA when the index is seen. The driver (called once every servo period) just checks if the index has been tripped in the previous cycle and if the counter has been reset.
This will probably cause a very small offset between the time the index is tripped, and encoder is reset and the time your stepgen sees this and updates it's internal position to 0.

Regarding the reset pin, I would rather connect and watch the index-enable pin which is used for communications between motion controller and encoder counter (when index-enable is high, the encoder knows to look for index and reset counters when it sees it). Once the counters have been reset the index-enable pin is pulled low by the encoder counter.
In stepgen if you would have that pin as an input, you would just save state and once it's gone high on the next transition to low you would set the -fb to point to -cmd.

Just my 2 cents
Regards,
Alex