homing & encoders

More
27 May 2009 10:36 #359 by gtom
Replied by gtom on topic Re:homing & encoders
Following a Hal scope

Attachments:

Please Log in or Create an account to join the conversation.

More
27 May 2009 10:49 - 27 May 2009 10:52 #360 by gtom
Replied by gtom on topic Re:homing & encoders
From left to right:

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???

in the middle section you can see where the motor "runs away".
Last edit: 27 May 2009 10:52 by gtom.

Please Log in or Create an account to join the conversation.

More
27 May 2009 14:34 #361 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re: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.

Please Log in or Create an account to join the conversation.

More
27 May 2009 16:02 - 27 May 2009 16:06 #362 by gtom
Replied by gtom on topic Re:homing & encoders
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???

Attachments:
Last edit: 27 May 2009 16:06 by gtom.

Please Log in or Create an account to join the conversation.

More
27 May 2009 16:15 - 27 May 2009 16:46 #363 by gtom
Replied by gtom on topic Re:homing & encoders
Tell me if im wrong:

Position is i.E. 5 when the index is hit,
encoder is reset to 0,
The traj sets the cmd position also to 0, right?
The stepgens Position-Feedback remains untouched -> As i can see in the scope
What happens then?
Why is the pos-fb not also set to 0. I think the encoder is 0, real position is 0,
cmd position is 0 at this point, just the fb is somewhere else... ???

I think that there always will be a joint-follow-error in that case!
If i understand this right then a joint follow error occurs when difference betw.
cmd-pos & pos-fb is greater than FMIN_ERROR, is this true?
If Yes, homing on index cannot work !?

What a also do not understand:
After the index was hit the cmd-pos should stay parallel to the encoder position. It seems that the stepgen wants to return to the "last" move or he wants to get near the fb, but in both cases the cmd-pos is far away from the encoder- position. The desired behaivour is a "step" in the scope for all three values, isnt it?
Last edit: 27 May 2009 16:46 by gtom.

Please Log in or Create an account to join the conversation.

More
27 May 2009 18:40 #364 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
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. :P

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

Please Log in or Create an account to join the conversation.

More
28 May 2009 21:49 #365 by gtom
Replied by gtom on topic Re:homing & encoders
Well, i dont think that my machine is set up incorrectly.... :-)

i looked thru the code of stepgen today, what do you think about setting the stepgens position_fb to the same value as the position_cmd when the enable-signal changes to false ???
This happens if a.) there is an error (like joint-follow-errors) and the machine needs to be homed to find the right position again or b.) if the machine is turned off -> in this case the fb Is the same as the position_cmd. Both cases should allow to set the fb = cmd.
And i can use the enable-signal at the time the index is hit to reset the position-fb...
Just an idea.
Question: ive tried *hm.instance.... position_fb = *hm.instance.... position_fb, this does not work, think i have to set count instead, cause fb seems to be a readonly- value (calculated by subcounts & scale) How do i calculate from a given position the count/subcount?

Please Log in or Create an account to join the conversation.

More
30 May 2009 00:51 #366 by gtom
Replied by gtom on topic Re:homing & encoders
Hi seb, what do you think about this:

Reset is an additional halpin.

void hm2_stepgen_prepare_tram_write(hostmot2_t *hm2, long l_period_ns) {
int i;
for (i = 0; i < hm2->stepgen.num_instances; i ++) {
if (*(hm2->stepgen.instance.hal.pin.reset) == 1) {
*(hm2->stepgen.instance.hal.pin.reset) = 0;
hm2->stepgen.instance.subcounts = 0;
}
if (*(hm2->stepgen.instance.hal.pin.enable) == 0) {
hm2->stepgen.step_rate_reg = 0;
hm2->stepgen.instance.subcounts = *(hm2->stepgen.instance.hal.pin.position_fb) * (hm2->stepgen.instance.hal.param.position_scale * 65536.0);
} else {
hm2_stepgen_instance_prepare_tram_write(hm2, l_period_ns, i);
}
}
}

Please Log in or Create an account to join the conversation.

More
30 May 2009 01:11 #367 by gtom
Replied by gtom on topic Re:homing & encoders
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

Please Log in or Create an account to join the conversation.

More
30 May 2009 07:10 #368 by alex_joni
Replied by alex_joni on topic Re:homing & encoders
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

Please Log in or Create an account to join the conversation.

Time to create page: 0.087 seconds
Powered by Kunena Forum