Homing with CoreXYU resets other head positions on endstop

wesc

@deckingman said in Homing with CoreXYU resets other head positions on endstop:

..........do you mean that if you home just X say, then the Y and Z will also be flagged as homed? Or do you mean something else?

It's sorta worse. Y has to be homed first due to the endstop placement (though that isn't the source of the problem here). If X is then homed it is set to the correct value as specified in M208 and the other axis (Y and U) are reset to 0 when the endstop is hit. The other axis remain unhomed. Similarly if U is then homed, X and Y are reset to 0. This happens both in homeall.g, or if homey.g, homex.g and homeu.g are run in sequence.

fcwilt

Here is a long shot. In your M574 you have E0:0. The docs say this is invalid for current firmware.

Frederick

wesc

@fcwilt Thanks. No change with E0:0 removed

cdl1701yahoo.com

@wesc
Mine is a CoreXY with the U being the tool locking for my tool changer. If you think that will help I will post my config and home files.

wesc

@cdl1701yahoo-com said in Homing with CoreXYU resets other head positions on endstop:

@wesc
Mine is a CoreXY with the U being the tool locking for my tool changer. If you think that will help I will post my config and home files.

Probably different enough to not be useful here. I've been looking over a lot of RRF code trying to figure out this. There's a lot of special processing that happens with endstops when processing G1 that is different for machines with multiple axis that move to cause motion on a logical axis. Looks like this grew out of Delta work and somehow my config is causing this special code to run in a way that's resetting all the coordinates on endstop triggers.

dc42

@wesc said in Homing with CoreXYU resets other head positions on endstop:

@cdl1701yahoo-com said in Homing with CoreXYU resets other head positions on endstop:

@wesc
Mine is a CoreXY with the U being the tool locking for my tool changer. If you think that will help I will post my config and home files.

Probably different enough to not be useful here. I've been looking over a lot of RRF code trying to figure out this. There's a lot of special processing that happens with endstops when processing G1 that is different for machines with multiple axis that move to cause motion on a logical axis. Looks like this grew out of Delta work and somehow my config is causing this special code to run in a way that's resetting all the coordinates on endstop triggers.

This sounds weird. What should happen is the following:

If your G1 H1 command moves only one axis, it should move that axis (or that tower if it is a delta). If the endstop is triggered before the end or the move, on a non-delta the position of that axis will be set to the M208 upper or lower limit, depending on whether you specified the endstop as being at the high or low end of the axis in M574.
If your G1 H1 command moves more than one axis, it should move those axes. If an endstop is triggered before the end of the move, what happens next depends on the kinematics. On a delta, the other towers continue moving until their endstops are triggered. Otherwise, if the axis whose endstop has triggered shares motors with any other axes (e.g. the X and Y axes in a CoreXY), the whole move is terminated. Otherwise (e.g. on a Cartesian printer), the other axes continue moving. In all cases, only axes whose endstops have been triggered should have their positions reset.

What happens if you home just X, or just Y?

wesc

@dc42 said in Homing with CoreXYU resets other head positions on endstop:et.

What happens if you home just X, or just Y?

If I home Y then Y gets set to yMax from m208
If I then home X, x gets set to xMin but y And u gets reset to 0. Same for then homing U - the other axis reset to 0.

The home*.g scripts are in the original post. The zero-ing happens on the first H1 move.

(Also, Upgrading to latest release didn’t change things)

lars

Hi, I have recently resumed my corexyu project and ran into a similar issue when trying to home one of the x, y or u axis. It zeroed/reseted the other two axis after homing. I have upgraded the firmware to 3.1.1 and started config from scratch as my old sd-card was broken.
I looked at the code and from my very limited understanding of it it looks like it sets all axis when trying to home one axis.

void CoreKinematics::OnHomingSwitchTriggered(size_t axis, bool highEnd, const float stepsPerMm[], DDA& dda) const
{
	const float hitPoint = (highEnd) ? reprap.GetPlatform().AxisMaximum(axis) : reprap.GetPlatform().AxisMinimum(axis);
	if (HasSharedMotor(axis))
	{
		float tempCoordinates[MaxAxes];
		const size_t numTotalAxes = reprap.GetGCodes().GetTotalAxes();
		for (size_t axis = 0; axis < numTotalAxes; ++axis)
		{
			tempCoordinates[axis] = dda.GetEndCoordinate(axis, false);
		}
		tempCoordinates[axis] = hitPoint;
		dda.SetPositions(tempCoordinates, numTotalAxes);
	}
	else
	{
		dda.SetDriveCoordinate(lrintf(hitPoint * inverseMatrix(axis, axis) * stepsPerMm[axis]), axis);
	}
}

CoreKinematics::OnHomingSwitchTriggered builds a array (tempCoordinates) for all axis. Sets the homing axis to its max or min limit in the array and then uses the array in dda.SetPositions. I’m suspecting that dda.GetEndCoordinate used to get position for all the axis that was not homing returns zeros for some reason.

// Get a Cartesian end coordinate from this move
float DDA::GetEndCoordinate(size_t drive, bool disableMotorMapping)
pre(disableDeltaMapping || drive < MaxAxes)
{
	if (disableMotorMapping)
	{
		return Move::MotorStepsToMovement(drive, endPoint[drive]);
	}
	else
	{
		const size_t visibleAxes = reprap.GetGCodes().GetVisibleAxes();
		if (drive < visibleAxes && !flags.endCoordinatesValid)
		{
			reprap.GetMove().MotorStepsToCartesian(endPoint, visibleAxes, reprap.GetGCodes().GetTotalAxes(), endCoordinates);
			flags.endCoordinatesValid = true;
		}
		return endCoordinates[drive];
	}
}

If I follow MotorStepsToCartesian it ends up back in CoreKinematics::MotorStepsToCartesian.

void CoreKinematics::MotorStepsToCartesian(const int32_t motorPos[], const float stepsPerMm[], size_t numVisibleAxes, size_t numTotalAxes, float machinePos[]) const
{
	// If there are more motors than visible axes (e.g. CoreXYU which has a V motor), we assume that we can ignore the trailing ones when calculating the machine position
	for (size_t axis = 0; axis < numVisibleAxes; ++axis)
	{
		float position = 0.0;
		const size_t motorLimit = min<size_t>(numVisibleAxes, lastMotor[axis] + 1);
		for (size_t motor = firstMotor[axis]; motor < motorLimit; ++motor)
		{
			const float factor = forwardMatrix(motor, axis);
			if (factor != 0.0)
			{
				position += factor * (float)motorPos[motor] / stepsPerMm[motor];
			}
		}
		machinePos[axis] = position;
	}
}

This function uses the “forwardMatrix” to calculate the result.
I had previously noticed getting a “Invalid kinematics matrix” when running

M669 K5 X1:1:0:0:0 Y-1:1:0:-1:1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:0

I need this to get the axis to move correctly. I noticed I got the same error message if I ran “M669 K5” without the movement coefficients so I ignored it. Now, looking at the code that generates the error message, it also zeros the “forwardMatrix”.

forwardMatrix.Fill(0.0);
reprap.GetPlatform().Message(ErrorMessage, "Invalid kinematics matrix\n");

That would cause MotorStepsToCartesian to report back all zeros and cause the homing problem.
Have I specified invalid movement coefficients? (It works for normal movement)

M669 K5 X1:1:0:0:0 Y-1:1:0:-1:1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:0

Is the default “inverseMatrix” that you get from “M669 K5” invalid.
Is the validation of the “inverseMatrix” bugged?

const bool ok = tempMatrix.GaussJordan(MaxAxes, 2 * MaxAxes);

lars

I slept on it and come up with a solution.
I need to set visible axis to 5 instead of the 4 that is proper for corexyu.

M584 P5

And I need to provide a movement coefficient matrix that has an inverse:

M669 X1:1:0:0:0 Y-1:1:0:-1:1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:1

I’m thinking that the problem is the default setting of “inverseMatrix(4, 4) = 0.0” when using corexyu in CoreKinematics::CoreKinematics. This will give a matrix without an inverse. And when trying to set the movement coefficients with only 4 axis visible the V coefficients are ignored by CoreKinematics::Configure and left set to zero.

Configuration that worked for me:

G90                                             ; send absolute coordinates...
M83                                             ; ...but relative extruder moves
M550 P"CoreXYU"                                 ; set printer name
M669 K5

; Network
M552 S1                                         ; enable network
M586 P0 S1                                      ; enable HTTP
M586 P1 S0                                      ; disable FTP
M586 P2 S0                                      ; disable Telnet

; Drives
M569 P4 S0                                      ; XYU Left Top, DW2 E1, First from  top, physical drive 4 goes forwards
M569 P3 S1                                      ; XYU Left Bottom, DW2 E0, Second from  top, physical drive 4 goes forwards

M569 P9 S0                                      ; XYU Rigth Top, DX5 E6, First from  top, physical drive 9 goes forwards
M569 P8 S1                                      ; XYU Rigth Bottom, DX5 E5, Second from  top, physical drive 8 goes forwards

M584 X4 Y8 Z0 U3 V9 E1:2 P5                           ; set drive mapping
M669 X1:1:0:0:0 Y-1:1:0:-1:1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:1
M584 P4

dc42

I'm glad you solved it. You should be able to set the visible axes to 4 except during configuration and homing. You may even be able to leave them as 4 during homing, now that you have a valid inverse matrix.

What OnHomingSwitchTriggered does is:

Work out where each motor is, based on how much of the move was executed before it was stopped by a homing switch, and set the axes to those positions.
Overwrite the coordinate whoe homing switch was triggered by the homing switch position that was specified in M208.