Homing with CoreXYU resets other head positions on endstop

[cdl1701yahoo.com]

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

M584 X0 Y1 Z2 U3 V4 E5:6 P4 ; Apply custom drive mapping

I have recently also had issues with getting my U axis working correctly and not screwing with the other axes. What I did was move my M584 U# to be above all other commands in my config in the general preferences and all my issues went away. Also, your M669 command has to be after the M584 commands.

[wesc]

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

I have recently also had issues with getting my U axis working correctly and not screwing with the other axes. What I did was move my M584 U# to be above all other commands in my config in the general preferences and all my issues went away. Also, your M669 command has to be after the M584 commands.

Thanks for the suggestions. Unfortunately they didn't fix the problem. Do you have a CoreXYU? If so, can you share your config and home files?

[deckingman]

@wesc I don't have a CoreXYU - mine is a bit different being a CoreXYUVAB. But what leaps out at me from your config.g is that, as well as the M584 being in the wrong place as @cdl1701yahoo-com pointed out, you've also defined the motor mapping as CoreXYUV. So there may be a conflict between the kinematics being set to CoreXYU in your M669 K5 and the motor mapping being set to Core XYUV in your M584. Try removing all those references to the V axis if your aren't using it (steps per mm, accelerations, speeds etc), as well as removing it from M584.

Probably not related to your problem but I've also noticed that in your M201 you have the acceleration for Z set to both 2500 and later 200. And is there a reason for the very weird looking acceleration settings of 4492 mm/sec^2?

[wesc]

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

@wesc I don't have a CoreXYU - mine is a bit different being a CoreXYUVAB. But what leaps out at me from your config.g is that, as well as the M584 being in the wrong place as @cdl1701yahoo-com pointed out, you've also defined the motor mapping as CoreXYUV. So there may be a conflict between the kinematics being set to CoreXYU in your M669 K5 and the motor mapping being set to Core XYUV in your M584. Try removing all those references to the V axis if your aren't using it (steps per mm, accelerations, speeds etc), as well as removing it from M584.

I got rid of the references to V and the problem persists (I'm unclear how exactly the 4th motor necessary for CoreXYU gets it's microsteps, drive assignment, and steps/mm. maybe it inherits it from the U drive and RRF assumes the next physical drive is V? Seems weird.

Probably not related to your problem but I've also noticed that in your M201 you have the acceleration for Z set to both 2500 and later 200. And is there a reason for the very weird looking acceleration settings of 4492 mm/sec^2?

This machine used to be a regular CoreXY. Those XY numbers are inherited from using Kisslicer's incredibly useful <TUNINGVAL> wizard which I have used to tune nearly every RRF tunable parameter. Surprisingly there was a lack of ringing/resonance at 4492 (also at 1/2 and 1/4 that). For purposes of bootstrapping this machine, i have now reverted them to a conservative 1000.

Current config.g:
; ---------------------------------------------------------------------------------------------------------
;
; TUBECORE config.g
;
; ---------------------------------------------------------------------------------------------------------

; General preferences

G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves

; Network
M550 PTubeCore ; Set machine name
M552 P192.168.1.111 S1 ; Enable network and set IP address
M553 P255.255.255.0 ; Set netmask
M554 P192.168.1.1 ; Set gateway
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

; Drives
M569 P0 S0 F8 ; Drive 0 goes backwards
M569 P1 S0 F7 ; Drive 1 goes backwards
M569 P2 S1 ; Drive 2 goes forwards (z)
M569 P3 S1 F6 ; Drive 3 goes forwards
M569 P4 S1 F6 ; Drive 4 goes forwards F6 is blanking time, diff for every stepper to make idle noise less
; Extruders
M569 P5 S1 ; Lefty, Drive 5 goes backwards
M569 P6 S1 ; Righty, Drive 6 goes backwards

M584 X0 Y1 Z2 U3 E5:6 P4 ; Apply custom drive mapping

M669 K5 ; Select CoreXYU mode

M350 X16 Y16 U16 I1 ; 16 microstepping interpolation
M350 Z16 I1
M350 E16:16 I1
M92 X200 Y200 Z400 U200 E420:420 ; Set steps per mm 16T pulley, BMGs
; Z: 1.8deg stepper, 10:1 gear, 16 uSteps, 40T GT2 - (2001016)/(40*2)

; **************************************
; * SPEED, ACCEL and JERK
; **************************************
M203 X24000 Y24000 U24000 Z4000 E3600:3600 ; Set maximum speeds (mm/min) - keep in sync with macros/ZPostprint.g
M201 X1000 Y1000 U1000 Z200 E1000:1000 ; Set accelerations (mm/s^2)
M566 X400 Y400 U400 Z25 E300:300 ; Set maximum instantaneous speed changes (mm/min)
;M593 F12 ; Set Dynamic Acceleration Adjustment (mm/s^2, avoid this acel)
M906 X1200 Y1200 U1200 Z1200 E800:800 I25 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X-209:135 Y-142:142 Z0:300 U-134:186 ; Set axis minima and maxima

; Endstops
M574 X1 Y2 Z1 U2 E0:0 S1 ; Endstops X and Low End, Y and High, U at High.

; Z-Probe
M557 X-120:120 Y-120:120 S40 ; Define mesh grid
M558 P5 I1 F500 H10 ; inductive NPN probe
G31 X0 Y0 Z0.8 ; Set Z probe trigger value, offset and trigger height

; Define locations of 3 leadscrew pivots
; corner M671 X-25:294:134 Y-16:-16:340 S10 ; SXX is max to trim leadscrews to level
;M671 X-165:154:-6 Y-156:-156:200 S10 ; SXX is max to trim leadscrews to level

; Heaters
; Bed
;M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
;M143 H0 S120 ; Set temperature limit for heater 0 to 120C
;M140 H-1 ; Disable Bed Heater

; Lefty
M305 P3 R4700 T100000 B4725 C7.06e-8 ; E3D V6 Semitec GT-104 thermistor cartridge
M143 H3 S280 ; Set temperature limit for heater 3 to 280C
M307 H3 A562.9 C267.0 D9.0 B0 ; Heater 1 (hot end) use PID -- increased gain by 10% (wes was 512.9)
; Righty
M305 P4 R4700 T100000 B4725 C7.06e-8 ; E3D V6 Semitec GT-104 thermistor cartridge
M143 H4 S280 ; Set temperature limit for heater 3 to 280C
M307 H4 A562.9 C267.0 D9.0 B0 ; Heater 1 (hot end) use PID -- increased gain by 10% (wes was 512.9)

; Fans
// part cooling fan
;M106 P0 S0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
;M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P3 S0 I0 F500 H-1 C"Lefty" ; Lefty part cooling , Fan 3, Heater 3
M106 P4 S0 I0 F500 H-1 C"Righty"

; Tools
M563 P0 D0 H3 F3 S"Lefty" ; Define tool 0, Drive 0, Heater 3 (duex5) Fan 3 (duex5)
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

M563 P1 D1 H4 F4 S"Righty" ; Define tool 1, Drive 1, Heater 4 (duex5), Fan 4 (duex5)
G10 P1 X0 Y0 Z0 ; Set tool 1 axis offsets
G10 P1 R0 S0 ; Set initial tool 1 active and standby temperatures to 0C

M564 H0 ; Allow movement for axis that haven't been homed.

; set up water cooling test
;M563 P2 S"Water" H2
;M305 P2 R4700 T100000 B4725 C7.06e-8 ; E3D V6 Semitec GT-104 thermistor cartridge
;M143 H2 S280 ; Set temperature limit for heater 1 to 280C

; Extruder configuration
M200 D1.75 ; Filament Diameter
M404 N1.75 D0.40 ; Filament Diam, and assume 0.40 nozzle
M207 S0.8 F1200 T1200 ; Set retract length and speed in case slicer emits hardware retracts.

; Miscellaneous
T0 ; Select first tool

M501 ; Execute config-override.g

[deckingman]

@wesc Hmmmm. I wonder if I understand your problem correctly.

By this (quote).........
"When successive endstops are hit (for X, Y and Z), the head position resets to 0 for the other axis".

..........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?

[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:

1. 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.
2. Overwrite the coordinate whoe homing switch was triggered by the homing switch position that was specified in M208.