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

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

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

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

@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)

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'