Homing issue - Cartesian with dual Y motors

dc42

I forgot to answer the second part of your question. Emergency Stop does not yet stop drives or turn off heaters attached to expansion boards.

too

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

Emergency Stop does not yet stop drives or turn off heaters attached to expansion boards

Good to know.

I have also noticed, when doing a firmware update on the expansion board the console frames that in a blue box and give the comment "Board n about to start a firmware update", but the update of the main board does not do that (M997 B0).

Now after testing the update, the X and Z axis are homing, but the Dual Y axis isn't, it is also not showing the triggering in the "Machine Specific" tab..

too

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.

too

After starting the machine this morning, dual homing on the Y axis no longer works.
Actually, the Y axis does not react to a triggered endstop on either side anymore, however the machine specific section registers these triggers.
Changing the configuration to use just one endstop for the two y axis motors does not help either.

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.1.0.5
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12+1 (2019-11-11b1)

My configuration:

; Drives
M569 P2.2 S1                                   ; physical drive X 2.2 goes forwards
M569 P1.1 S1                                   ; physical drive Ymin 1.0 goes forwards
M569 P1.2 S0                                   ; physical drive Ymax 1.1 goes backwards
M569 P0.0 S1                                   ; physical drive Z 0.0 goes forwards
M569 P2.1 S1                                   ; physical drive E 2.1 goes forwards
M584 X2.2 Y1.1:1.2 Z0.0 E2.1                   ; set drive mapping

; Endstops
M574 X1 S1 P"2.io2.in"                         ; configure active-high endstop for low end on X via pin 2.io0.in
M574 Y1 S1 P"1.io3.in+1.io2.in"                ; configure active-high endstop for low end on Ymin via pin 1.io3.in and Ymax via pin 1.io2.in
M574 Z1 S1 P"!0.io4.in"                        ; configure active-high endstop for low end on Z via inverted pin 0.io4.in

I am not sure what has changed since yesterday, besides power cycling the machine.

dc42

Check that both the main and expansion boards are running the correct firmware versions. I have heard of an instance of DSF reinstalling old firmware when it starts up.

too

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

Check that both the main and expansion boards are running the correct firmware versions

how would I do that for the expansion boards?

M112 is giving me the following output:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.0beta12+1 running on Duet 3 MB6HC
Board ID: 08DGM-9T66A-G63SJ-6JKDL-3SD6R-TS03A
Used output buffers: 1 of 32 (5 max)
=== RTOS ===
Static ram: 122240
Dynamic ram: 168636 of which 0 recycled
Exception stack ram used: 272
Never used ram: 102068
Tasks: NETWORK(ready,2044) HEAT(blocked,1204) CanReceiv(suspended,3520) CanSender(suspended,1480) CanClock(blocked,1428) TMC(blocked,216) MAIN(running,4212) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:03:00 ago, cause: power up
Last software reset at 2019-11-19 12:01, reason: User, spinning module LinuxInterface, available RAM 101904 bytes (slot 2)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 22.7, current 30.1, max 30.2
Supply voltage: min 23.6, current 23.6, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
Driver 0: standstill, reads 23723, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 23728, writes 11 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 23728, writes 11 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 23729, writes 11 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 23730, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 23731, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2019-11-19 15:15:57
Slowest loop: 4.97ms; fastest: 0.25ms
=== Move ===
Hiccups: 0, FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon* is ready with "M122" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.74ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8
- Ethernet -
State: 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 662, longest wait 2ms for type 6036
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 24ms ago
RX/TX seq numbers: 4992/4993
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.1.0.5
Code buffer space: 4096
Configured SPI speed: 2000000 Hz
Full transfers per second: 0.91

As far as I understand, Beta12+1 should be the one you linked to earlier.
I have installed both the EXP3HC and the MB6HC from your dropbox link.

droftarts

Send M122 B1 for the first expansion board, M122 B2 for the second. As it says in M122.

Ian

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.