Homing issue - Cartesian with dual Y motors

too

Oh wow, of course, how embarrasing

This is what I get from the expansion boards:

M122 B2
Diagnostics for board 2:
Board EXP3HC firmware 3.0beta1 2019-11-08b2
Never used RAM 163.0Kb, max stack 436b
HEAT 1136 CanAsync 1428 CanRecv 1424 TMC 168 AIN 532 MAIN 2180
Driver 0: standstill, reads 19625, writes 11 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 19621, writes 17 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 19624, writes 18 timeouts 0, SG min/max 0/135
Move hiccups: 0
VIN: 23.9V, V12: 12.2V
MCU temperature: min 45.2C, current 45.2C, max 45.6C
Ticks since heat task active 33, ADC conversions started 1314776, completed 1314776, timed out 0

M122 B1
Diagnostics for board 1:
Board EXP3HC firmware 3.0beta1 2019-11-08b2
Never used RAM 163.2Kb, max stack 489b
HEAT 1284 CanAsync 1428 CanRecv 1392 TMC 28 AIN 532 MAIN 2220
Driver 0: standstill, reads 57330, writes 11 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 57328, writes 15 timeouts 0, SG min/max 0/323
Driver 2: standstill, reads 57331, writes 15 timeouts 0, SG min/max 0/348
Move hiccups: 0
VIN: 24.0V, V12: 12.2V
MCU temperature: min 50.1C, current 50.2C, max 50.2C
Ticks since heat task active 242, ADC conversions started 1310986, completed 1310985, timed out 0

too

bump bump

droftarts

You may have to wait for @dc42 to reply to resolve this; I don't have a Duet 3 and expansion board to test. He's away in Germany this week.

However, if you got it working the other day, I'd suggest that you manually typed in something that corrected the issue, that didn't get updated to config.g or your macros. Retrace your steps! Perhaps:

@too said in Homing issue - Cartesian with dual Y motors:

Actually, after looking again I realised I got a "Error: M574: Pin 1.io1.in is not free" In the console.
After changing the two endstops to a different IO port it shows up in the machine specific section as triggered and the axis homes just fine.

Ian

too

@droftarts I have tried all the other pins on the expansion board, with no success. I will try and replace the board to see if that might change something - It did work for a while after all..

Let's see what @dc42 says when he's back.

too

I have now replaced the expansion board that controls the two Y motors + their endstops, but stil can't make the homing on the Y axis work.

@dc42 Could it be an issue in the firmware? Have you tested the dual motor + dual endstop on an extension board?

deckingman

@too I'm curious as to how you want this to work. If you have 2 Y motors and two end stops, I'd assume that you have one motor and one end stop at each end of the axis yes? If so I'd also assume that want to be able to move both motors until one or other end stop triggers, then move each motor in turn until each individual end stop triggers, so that both end stops are triggered yes? If that's the case, then I think the only way to do that is to create another axis, say U. Then you spilt the motor mapping and assign one motor to Y and the other to U. Then move both Y and U together until one or other end stop triggers, then move Y and U independently so that both end stops trigger. Then finally re-map both motors to back to Y.

But I don't see any axis other than Y defined in your config.g . Unless I've missed something, I can't see how else you could move Y using 2 motors until both end stops trigger. Can you post your latest config.g in full as well as your homing files.

Edit - answered my own question when I re-read the overview for RRF 3 which states that it is not necessary to split axes during homing.

dc42

@too said in Homing issue - Cartesian with dual Y motors:

I have now replaced the expansion board that controls the two Y motors + their endstops, but stil can't make the homing on the Y axis work.

@dc42 Could it be an issue in the firmware? Have you tested the dual motor + dual endstop on an extension board?

Please post your complete config.g and homing files, and I will try to reproduce this.

too

@dc42 here you go
config (3).g
homex.g
homey.g
homez.g

too

@dc42 any updates?

too

@dc42 Sorry if I am being annoying, but did you guys look into this yet?

dc42

Have you re-tested this using RRF 3.0RC1 on both the main board and the expansion boards? I think it is probably fixed.

There is one remaining known issue with endstops, which is that an endstop connected to the main board will not stop a motor connected to an expansion board unless a motor connected to the main board is moving too.

dc42

@too, please test again with release 3.0 stable.