How are the axis coordinates supposed to be set when homing?

bondus

I'm still working on my strange arm-printer. It now has a rotating tower.

I am struggling to get homing to work properly. The homing movements works fine (with a custom homing file), but the cartesian axes are not always set right, the results depends on they were before I started homing. The values are usually reasonable but off a few millimeters. (It gets pretty violent in my case when the rotating base decides to take the long route to get to the other side of the end stop. That poor monitor in the background have taken quite a beating)

It works if I set the homing position in the custom homing gcode file using G92. But the smallest change to any configuration means I have to do some quite intricate trigonometry by hand to calculate the new home position, not fun.

OnHomingSwitchTriggered() is implemented properly (I think) so the motor positions are set properly. But the cartesian coordinates are not set properly.

I have verified and re-verified that CartesianToMotorSteps and MotorStepsToCartesian are actually the inverse of each other.

How are the axis coordinates supposed to be set when homing?

dc42

The axes coordinates get computed from the motor steps that you set when you call dda.SetDriveCoordinates from OnHomingSwitchTriggered. I suggest you connect a PC via USB, then send M111 s1 P4 and M111 s1 P6 to enable Move and DDA debugging. After homing you should see a message similar to this:

Forward transformed 63256 63096 63176 to -1.71 -0.00 452.00

This indicates the result of the call to MotorStepsToCartesian that the firmware made to calculate the axis position. So you will be able to see whether you are setting the motor steps consistently. If you are not, then that suggests that the homing switch trigger positions are not consistent. Are you backing off after they trigger, then moving towards them slowly until they trigger again?

The motor step positions are also reported in the M114 command.

bondus

After many hours of staring at code and adding debug printouts everywhere I finally found the error.

In config.g there was the line:
M574 X2 S0 ; Set active high endstops, min
should have been:
M574 X1 S0 ; Set active high endstops, min

My homing code for X was never executed!

Looking for that problem I found an other interesting thing.

I had my transform function treat all points on the other side of the endpoint (negative position of tower rotating motor) as being one whole rotation away. i.e a position of -1 would be treated as +359. I have the position of the rotating motor in degrees. This causes quite some confusion and squeaking steppers with even the smallest step past the endpoint.

I don't need to tower to be able spin 360 degrees, it would tangle the cables. If you do want the tower to rotate multiple laps the cartesian->motor transform function would have to keep track of what lap you are on and select the appropriate stepper position.

Those M111 commands never turned on that "Forward transformed" logging, that print is not anywhere in my version of the firmware. I'm in the dev branch. But it was simple to add some of my own.

dc42

@bondus said in How are the axis coordinates supposed to be set when homing?:

I don't need to tower to be able spin 360 degrees, it would tangle the cables. If you do want the tower to rotate multiple laps the cartesian->motor transform function would have to keep track of what lap you are on and select the appropriate stepper position.

RRF already does that for you, if your kinematics returns true from the call to IsContinuousRotationAxis for that axis.

Those M111 commands never turned on that "Forward transformed" logging, that print is not anywhere in my version of the firmware. I'm in the dev branch. But it was simple to add some of my own.

I forgot, I re-added them recently. They are in last night's commit and possibly in the one before that.

bondus

@dc42 said in How are the axis coordinates supposed to be set when homing?:

@bondus said in How are the axis coordinates supposed to be set when homing?:

I don't need to tower to be able spin 360 degrees, it would tangle the cables. If you do want the tower to rotate multiple laps the cartesian->motor transform function would have to keep track of what lap you are on and select the appropriate stepper position.

RRF already does that for you, if your kinematics returns true from the call to IsContinuousRotationAxis for that axis.

Neat. It's implemented very simple, nice.

I can see that the Scara model makes heavy use of that. You can build some very strange Scaras.