Step/Dir servos + Encoders = follow errors... and so much pain.....

The firmware can capture the stepgen position at the index edge
(just like the encoder firmware can capture the encoder position
at index), but the hostmot2 driver needs to have the support for this
capability added. I intend to work on this in the next week or so.

That would be fantastic! thank you for offering to implement that

It is not in the handling of the index signal.

Basically, your servo drive needs to move X distance when it is commanded to do so with the STEP signal.
In a real stepper motor the driver will output modified phase currents to make this happen. There can be some lag but that's what we live with when we chose to use stepper motors.

For your servo drives to do the same thing there has to be a control loop that is checking that the servo motor is really moving X distance when asked to. The servo driver has a control loop by itself to make this happen. That's where you need to look, in the driver PID setting. That is what determines what happens at a a STEP pulse. The use of the motor encoder is not visible.

An alternative is to set this up as a real stepper motor control (step/dir right) without position feedback. In this case it is absolutely clear that deviations are caused by the driver/motor.

God luck man it is frustrating.

I think jhandel wants to home to index. This is not currently supported
by the hostmot2 driver for open loop step/dir systems but can be added.

yah previous experience with these homing switches is they are good to +/- >0.2mm which is not great when you have fixture plates and other known fixed items you don't want to have to constantly probe back in... Index pulse homing is good to +/-.002 (seriously crazy accurate).... So I am happy to live in Open Loop land, but index homing is super important..

And thank you PCW for offering to make the enhancement to hostmon2!

Ok that is some seriously intense low level code :pinch:

Start looking at it, having a bit of a time groking what all is going on.. makes since from a performance perspective but its not as straight forward as a neon sign saying "this is where homing counters are managed" in the encoder.c file or "this is the start of the homing sequence" in hostmot2.c lol...

If I am reading this right, I want to do something like this from encoder.c
hm2_encoder_instance_update_rawcounts_and_handle_index

in

stepgen.c (looks like in that first hm2_stepgen_process_tram_read method...

Step one though, will be setting up a linuxcnc dev environment and getting everything building...... but I think, maybe, I can track down the changes... If I get something that doesn't break my machine and I beat you to it, I'll send a pull request to linuxCNC..

I am assuming I should make the change in the 2.8 branch? (or does this go in the 2.8 pocket-fix?)

I have started working on this, It requires coordination of firmware and driver
modifications as well as firmware discovery changes to avoid breaking existing
installations. I would suggest that you wait. This belongs in master (2.9)

ok, I'll hold off then... I'll get ready to migrate to 2.9 then.. I guess I'll also have to rebuild my firmware once you have the code ready... Looking forward to checking out the changes in the diffs to get a better understanding how all of this works together..

I think jhandel wants to home to index. This is not currently supported
by the hostmot2 driver for open loop step/dir systems but can be added.

That would be awesome!

This is now supported in master (but untested other than manually verifying
that an index event clears the stepgen position)