homing & encoders

More
26 May 2009 01:25 - 26 May 2009 01:40 #348 by PCW
Replied by PCW on topic Re:homing & encoders
I suspect this problem arises because:

1. You are probably the first person using HM2 with an encoders index signal to home a stepper system.
2. The hardware position register in HM2s stepgen is not cleared by software when a index event is detected.

The driver software could clear the HM2 stepgens hardware position register when an index event is detected, but
this software fix is not really correct either (but much better than flying off to places unknown) because it will limit
homing speeds to < 1 step per sample. This may be ok depending on how homing is done.

What really should happen is that the hardware position register in HM2 stepgen should have the option
of being cleared when a hardware index event happens. This is simple in the hardware but I never anticipated the need :(
One messy part is that there would likely need to be some hardwired relationship between the encoder # and stepgen # that
are connected, or more involved, a select register in stepgen, to select which encoders index can clear its position register
Last edit: 26 May 2009 01:40 by PCW. Reason: omitted text

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

More
26 May 2009 15:17 #349 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
I agree with Peter's suspicions above.

If we go the route of having a "latch on index" feature in the stepgen, I would prefer a register in the stepgen that selected which encoder instance to look at, rather than having a hard-wired relationship compiled into the firmware.

But for now, steppers and encoders is certainly an unusual and tricky configuration. It can probably be made to work, but it does require significant thought and effort on part of the machine builder. You have two position feedbacks (encoder & stepgen) that intentionally give different results (otherwise why have two?). How are they unified?

Using the encoder index signal to clear the stepgen count accumulator would require the stepgen to have a "latch on index" feature mimicking the encoder's, otherwise the driver would not know to expect the accumulator to zero, and (correctly) freak out when it does.

Maybe you could hook up a falling-edge detector to the encoder index-enable pin, and use the output to reset the stepgen count? I dont know. You'll have to experiment and report back. Imagine the glory that will be yours when you commit a steppers+encoders sample config ;-)

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

More
26 May 2009 16:25 #350 by gtom
Replied by gtom on topic Re:homing & encoders
Hi Seb,

ive tested the encoder RESET today, same result, Stepgen accelerates, ignoring all limits. Well, using the index is not absolutely neccesary, it would be good to have the linear encoder running that way, also Homing would be much mor accurate than using switches... :-)

My steppers are running perfect with encoders... i wrote a small rt-component to keep the steppers running with less tolerances (using "real" table position given by the linear encoder)
Some Things need attention:
Backlash should be lower than the "real" Backlash
Correction is only done in the same direction than the axis moves

i made a lot of test, milling circles, pockets and so on, the results (tolerances) are much better than running the machine without encoders.

Here is the source (just the basics..)

component stepenc "connect a linear encoder to stepgen";

pin in float in "position command in";
pin in float enc "encoder input";
pin out float out "position command out";
pin in float vel "velocity command in";
pin in float limit "velocity limit";
pin out float corr "corrected value";

function _ fp "encoder for stepgen";
license "GPL";
;;
FUNCTION(_) {
float d = in - enc;
corr = 0;
if ((vel > 0) && (vel < limit))
{
if (d > 0)
{
out = in + d;
corr = d;
}
else
out = in;
}
else
if ((vel < 0) && (vel > -limit))
{
if (d < 0)
{
out = in + d;
corr = d;
}
else
out = in;
}
else
out = in;
}


off course, all tests of the Stepgen (index-enable, Reset, etc) were made without that comp... :-)

regards, Thomas

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

More
26 May 2009 17:34 #351 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
gtom wrote:

ive tested the encoder RESET today, same result, Stepgen accelerates, ignoring all limits.


I'm not sure what you mean by this.

Do you mean that when the encoder hits its index switch and resets its position to zero, the stepgen moves to it's zero position, ignoring the trajectory planner limits [AXIS_*]MAX_ACCELERATION and [AXIS_*]MAX_VELOCITY? That's what I would expected with this configuration: the machine hits the encoder index and instantly sets the stepgen's position-cmd to 0, bypassing the trajectory planner limits. The stepgen reacts to this by performing a trapeziodal move from the stepgen's idea of the limit switch position to the stepgen's idea of the 0 position. This is done by effecting constant acceleration at the stepgen.maxaccel limit up to the stepgen.maxvel limit, then cruising at stepgen.maxvel, then decelerating at stepgen.maxaccel back to 0 velocity at the stepgen's 0 position.

If instead you mean that the stepgen ignores it's own limits (hm2_*.0.stepgen.*.maxaccel and .maxvel) then we have a problem.

By the way, we fixed a couple of stepgen bugs at Fest, if possible please try with the current top of the 2.3 branch (or Trunk), or with 2.3.2 when it comes out.

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

More
26 May 2009 18:13 #353 by PCW
Replied by PCW on topic Re:homing & encoders
How is the index event passed to the software stepgen? Maybe that could be used as a model.
Even if the hardware is modified to support stepgen LOI or COI (COI is cheaper hardware wise)
the stepgen driver still needs to know about the index event

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

More
26 May 2009 18:58 #354 by gtom
Replied by gtom on topic Re:homing & encoders
To test the behaivour of stepgen ive set ALL vel & accels to very low values. Even with those values set low the stepgen was accellerating (i dont know if it is acceleraring even cause the axis moves extremely fast away, what causes joint-follow errors) seems that stepgen just starts stepping away...

The index stuff i do not understand: As Axis.*.index-enable is the only pin that is connected to the encoder how does the stepgen get its information to reset?

After the index was hit the stepgen.0.position-cmd jumps to -2.05 and the position-fb jumps to 8.2. i mean during the move towards the index, cmd and fb is always the same value and in the second when the index was hit there is a difference of 10.25mm.
The Value 2.05 is not correct (measured the most left position of the table and the fb value of 8.2 is also not correct cause the Tabled stopped after 5.2mm (joint-follow-error)

Thomas

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

More
26 May 2009 19:12 #355 by gtom
Replied by gtom on topic Re:homing & encoders
@seb:
Yes, it is ignoring ALL Vel & Accel Limits,
Can you tell me where Stepgens ZERO- position is?
If i turn the Table by hand in its 0-position (very close to the index) and turn the machine ON the Encoders are always 0.00. I think that this is Stepgens Zero-position, but even doing that Stepgen moves to the direction where it came from. And: It wants to move FAR away from that position, so i do not think that stepgen wants to move back to its own 0.00 position on a index-reset because that position was very near to the index (no matter if left or right from the index, same result)

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

More
26 May 2009 19:36 #356 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
PCW wrote:

How is the index event passed to the software stepgen? Maybe that could be used as a model.


The software stepgen is totally disconnected from the software encoder, just like in hostmot2.

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

More
26 May 2009 21:28 #357 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
gtom wrote:

To test the behaivour of stepgen ive set ALL vel & accels to very low values. Even with those values set low the stepgen was accellerating (i dont know if it is acceleraring even cause the axis moves extremely fast away, what causes joint-follow errors) seems that stepgen just starts stepping away...

The .hal file you posted above has stepgen's maxvel set to 0, which means "step as fast as the stepgen timings allow". The timings in your .ini have an 8 microsecond step, for a max step rate of 125 KHz. Your scale is 320, for a max velocity of 390 mm per second. That's fast. Your stepgen maxaccel is 8 millimeters per second per second, so it should take it a very long time to ramp up to 390 mm/s. So i dont understand the behavior you're seeing.

gtom wrote:

The index stuff i do not understand: As Axis.*.index-enable is the only pin that is connected to the encoder how does the stepgen get its information to reset?

The stepgen is not connected at all to the encoder index, this is the source of the problem you're having.

gtom wrote:

After the index was hit the stepgen.0.position-cmd jumps to -2.05 and the position-fb jumps to 8.2. i mean during the move towards the index, cmd and fb is always the same value and in the second when the index was hit there is a difference of 10.25mm.
The Value 2.05 is not correct (measured the most left position of the table and the fb value of 8.2 is also not correct cause the Tabled stopped after 5.2mm (joint-follow-error)

If it's not obeying your 8 mm/s/s accel limit, it may well be missing steps and ending up short of the commanded move.

Can you provide a halscope screengrab showing hm2 encoder position, stepgen position-cmd, and stepgen position-fb, starting just before the encoder index and lasting through the following error?

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

More
27 May 2009 03:11 #358 by Roguish
Replied by Roguish on topic Re:homing & encoders
Seb,
I think there is a similar (if not the same) in the servo implementation of hm2.
I am converting my m5i20 configuration to hm2 and have everything working except index homing.
Using SVST4_8.bit.

Noel.
'Roguish'

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

Time to create page: 0.100 seconds
Powered by Kunena Forum