Homing issue - Cartesian with dual Y motors



  • Hello!

    I am building a test machine with a duet3 and two expansion boards. I am trying to get homing working, but the machine does not stop the move when an endstop is triggered. Hitting the "EMERGENCY STOP" button in the Web interface also does not stop the move. In the Machine-Specific Tab on the Web interface the triggers are registered.

    I suspect I have made a mistake when changing the Config for the multiple Y motors, as the config tool did not allow for this option:

    ; 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 S1                                   ; physical drive Ymax 1.1 goes forwards
    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
    
    M350 X16 Y16 Z16 E16 I1                        ; configure microstepping with interpolation
    M92 X80.00 Y80.00 Z400.00 E1000.00             ; set steps per mm
    M566 X900.00 Y900.00 Z450.00 E120.00           ; set maximum instantaneous speed changes (mm/min)
    M203 X6000.00 Y6000.00 Z2500.00 E6000.00       ; set maximum speeds (mm/min)
    M201 X500.00 Y500.00 Z400.00 E250.00           ; set accelerations (mm/s^2)
    M906 X1000 Y1000 Z1200 E800 I30                ; set motor currents (mA) and motor idle factor in per cent
    M84 S30                                        ; Set idle timeout
    
    ; 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.io0.in+1.io1.in"                ; configure active-high endstop for low end on Ymin via pin 1.io0.in and Ymax via pin 1.io1.in
    M574 Z1 S1 P"!io0.in"                          ; configure active-high endstop for low end on Z via pin io0.in
    

    Any Ideas?


  • administrators

    The current released firmware (beta 12) doesn't support endstop switches on expansion boards. See https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations.

    There is an unreleased build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 that does. If you want to try it, update both the main and expansion board firmware from that folder.



  • Ah well, thanks, that explains things 😄
    I'll give the update a try!


  • administrators

    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.



  • @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.

    90ed4abc-0f01-4805-9dac-7f58e1990d9d-image.png

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



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



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


  • administrators

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



  • @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.



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

    Ian



  • 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
    


  • bump bump



  • 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



  • @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.



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



  • @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.


  • administrators

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





  • @dc42 any updates?


Log in to reply