New COREXY printer with Duet 3 issues



  • Hello, Duet enthusiasts.

    I'm trying to understand, what is wrong with my configuration files - coming from Marlin world, it's a bit difficult to
    set everything up on my own apparently.

    What I have done so far:
    assembled the hardware (Ratrig V-Core Pro), I have the original BLTouch, 3xZ-motors, SSR, 7" Paneldue. Everything seems to work.
    I configured the Duet 3 board not to use endstops, this also seems to work.

    At the moment I have installed Duet Web Control 2.0.7, Board: Duet 3 MB6HC v0.6 or 1.0 (MB6HC)
    DSF Version: 1.2.4.0
    Firmware: RepRapFirmware for Duet 3 MB6HC 3.01-RC5 (2020-03-27b3)
    I tried to update the board's firmware to 3.1.1, but after flashing the new firmware (via Pi and also tried via USB) the Duet 3 board
    was completely unresponsive. Rolled back to 3.05 because of that. I have another machine with Duet Wifi board, that I updated to
    the latest firmware version without any hassle.

    When I home X and Y individually, the gantry moves to the right direction, when homing X-axis, the hotend moves to the right, touches
    the right side of the gantry and stops there. When homing Y, the gantry moves forward and stops correctly. What puzzles me is the Z axis.
    When I move the Z, the motors work correctly and the bed moves to the right direction. When homing Z, it just starts to move downwards, away from BLtouch.
    When I reverse the Z motors, the bed starts to move upwards, but the BLTouch doesn't work, it will not stop the bed.

    I'll include the diagnostics and the configuration files here

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 3 MB6HC version 3.01-RC5 running on Duet 3 MB6HC v0.6 or 1.0
    Board ID: 08DJM-956L2-G43S4-6JTDJ-3S86T-985AD
    Used output buffers: 1 of 40 (40 max)
    === RTOS ===
    Static ram: 154084
    Dynamic ram: 160900 of which 68 recycled
    Exception stack ram used: 404
    Never used ram: 77760
    Tasks: ETHERNET(blocked,832) NETWORK(ready,2076) HEAT(blocked,1196) CanReceiv(suspended,3820) CanSender(suspended,1436) CanClock(blocked,1436) TMC(blocked,72) MAIN(running,4580) IDLE(ready,80)
    Owned mutexes:
    === Platform ===
    Last reset 00:34:17 ago, cause: power up
    Last software reset at 2020-06-06 00:49, reason: User, spinning module LinuxInterface, available RAM 78484 bytes (slot 2)
    Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0443c000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
    Error status: 4
    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 25.6, current 33.5, max 33.7
    Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
    12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
    Driver 0: standstill, reads 14138, writes 6 timeouts 0, SG min/max 0/210
    Driver 1: standstill, reads 14138, writes 6 timeouts 0, SG min/max 0/158
    Driver 2: standstill, reads 14138, writes 6 timeouts 0, SG min/max 0/192
    Driver 3: standstill, reads 14132, writes 12 timeouts 0, SG min/max 0/105
    Driver 4: standstill, reads 14131, writes 12 timeouts 0, SG min/max 0/174
    Driver 5: standstill, reads 14144, writes 0 timeouts 0, SG min/max not available
    Date/time: 2020-06-06 14:06:05
    Slowest loop: 3.51ms; fastest: 0.22ms
    === Move ===
    Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 46076ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 9, completed moves: 9, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
    === Heat ===
    Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
    === GCodes ===
    Segments left: 0
    Movement lock held by null
    HTTP* is ready with "M122" in state(s) 0
    Telnet is idle in state(s) 0
    File is idle in state(s) 0
    USB is idle in state(s) 0
    Aux is idle in state(s) 0
    Trigger* is idle in state(s) 0
    Queue is idle in state(s) 0
    LCD is idle in state(s) 0
    SBC is idle in state(s) 0
    Daemon* is idle in state(s) 0
    Autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 0.51ms; fastest: 0.03ms
    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: establishingLink
      Error counts: 0 0 0 0 0
      Socket states: 0 0 0 0 0 0 0 0
      === Filament sensors ===
      Extruder 0 sensor: no filament
      === CAN ===
      Messages sent 7828, longest wait 0ms for type 0
      === Linux interface ===
      State: 0, failed transfers: 0
      Last transfer: 21ms ago
      RX/TX seq numbers: 60774/60775
      SPI underruns 0, overruns 0
      Number of disconnects: 0
      Buffer RX/TX: 0/0-0
      === Duet Control Server ===
      Duet Control Server v1.2.4.0
      Code buffer space: 4096
      Configured SPI speed: 2000000 Hz
      Full transfers per second: 1.28

    config.g
    homeall.g



  • @Tanel_76

    Have you gone through the wiki files

    When you turn the printer on does the BLTouch go through its self-test (deploys and retracts the probe several times and the red LED stays lit)? If not there could be an open circuit or improper orientation for the BLTouch power pins.

    What happens if you manually deploy and retract the probe with M401 and M402? Does the probe operate properly? If not please post the deployprobe.g and retractprobe.g files and check the BLTouch wiring. Thre could be an open circuit or improper orientation for the BLTouch servo pins.

    If the probe does deploy and retract properly, what happens if you manually trigger the z probe by placing your finger under the pin while homing z to purposely trigger it early? Does the bed stop? If not there could be an open circuit or improper orientation for the BLTouch endstop pins.



  • I have gone through the BLTouch wiki files, the BLT is connected
    properly I think.

    The BLTouch does the self-test and the red LED is lit.
    M401 and M402 commands will not do anything, I can get the probe to deploy
    using M280 P0 S10 |1 command.

    Basically what happens is, that when I hit home all button, X and Y axis are
    working properly and Z is starting to move downwards.

    This is my
    ; deployprobe.g
    ; called to deploy a physical Z probe
    M280 P0 S10 |1; deploy BLTouch

    and this is
    ; retractprobe.g
    ; called to retract a physical Z probe
    M280 P0 S90 |1 ; retract BLTouch

    and
    ; bed.g
    M561 ; clear any bed transform

    ;G30 P0 X0 Y115 H0 Z-99999 ; probe near front left corner
    ;G30 P1 X275 Y115 H0 Z-99999 ; probe near front right corner
    ;G30 P2 X150 Y270 H0 Z-99999 S3 ; probe near rear center

    G30 P0 X5 Y110 H0 Z-99999
    G30 P1 X280 Y110 H0 Z-99999
    G30 P2 X150 Y270 H0 Z-99999 S3



  • @Tanel_76 new BLTouch need a pullup resistor activated now, so
    M558 P9 C"io7.in" F200 H5 R0.2 T9000 A1 B1
    change to
    M558 P9 C"^io7.in" F200 H5 R0.2 T9000 A1 B1

    (it is documented in https://forum.duet3d.com/topic/16093/upgrading-from-rrf2-to-rrf3-issues/4 )

    Please try that. If this doesn't help, I will check your config more closely.


  • administrators

    @Tanel_76 said in New COREXY printer with Duet 3 issues:

    M280 P0 S10 |1; deploy BLTouch

    Use I1 or i1 in those commands (letter-i digit-1), not the |1 (vertical-bar digit-1) which is what is in the lines you posted. However, as you are using RRF3 then you don't that part of the command at all. So use:

    ; deployprobe.g
    ; called to deploy a physical Z probe
    M280 P0 S10 ; deploy BLTouch

    ; retractprobe.g
    ; called to retract a physical Z probe
    M280 P0 S90 ; retract BLTouch



  • I'm using an old V2 BLTouch,

    I changed the deployprobe.g and retractprobe.g according to the instructions, still the same behavior - the machine homes X and Y, after that the hotend moves to the center, BLTouch does not deploy and the bed starts to move downwards.



  • @Tanel_76
    Did you try the ^ anyway? (just to be sure it is not the reason)



  • @Tanel_76
    for BLTouch V2 is a specific information in
    https://duet3d.dozuki.com/Wiki/BLTouch_Troubleshooting

    " Cut the Trace. Version2 BLTouch Smart probes have a trace on the PCB which can be cut to allow safe functionality with 3.3v logic board, such as that used by the Duet. Use a sharp xacto knife to cut the trace completely. Use a multimeter to verify that it is completely cut. The Duet should be able to handle it without cutting the trace, but there have been user reports of problems being resolved after making sure the trace is cut."
    Maybe this would help, but maybe someone can confirm that this solves the issue.

    On this page are other hints to test the BLTouch, also, which you can make to be sure the BLTouch is working.



  • @JoergS5 said in New COREXY printer with Duet 3 issues:

    M558 P9 C"^io7.in" F200 H5 R0.2 T9000 A1 B1

    I tried now the "M558 P9 C"^io7.in" F200 H5 R0.2 T9000 A1 B1" line - still the same issue.

    I did cut the 3.3v trace. Checked with multimeter - no continuity.



  • @Tanel_76 said in New COREXY printer with Duet 3 issues:

    no continuity

    I wonder why you have a second M915, after X and Y are homed. I cannot find information in the documentation whether it maybe resets the homing.



  • @Tanel_76 I am sorry, I have no additional ideas.



  • Thanks for your input JoergSS,
    actually homeall.g is a copy from another V-Core PRO printer, but yes - I noticed too,
    that up until the second 915 command everything seems to work.

    I'll try without it, let's see.



  • @Tanel_76 I found a little glitch in homeall:
    M574 X1 Y1 S3
    should not be used, from https://duet3d.dozuki.com/Wiki/Gcode#Section_M574_Set_endstop_configuration
    "Use a separate M574 command for each axis."

    And you have defined stall detection in config.g already.
    Whether it changes anything, I don't know.



  • I uncommented both, the M915 and M574, still the same behaviour...



  • @Tanel_76 Maybe you find the solution tomorrow, after thinking a night about it. Good luck! If I have an idea, I'll tell you of course.



  • @Tanel_76 Another possible finding in bed.g:
    I cannot find
    G30 P2 X150 Y270 H0 Z-99999 S3
    the S3 parameter in documentation, maybe you meant S-3:
    https://duet3d.dozuki.com/Wiki/Gcode
    "G30 S-3 ; Probe the bed and set the Z probe trigger height to the height it stopped at (supported in RRF 2.03 and later)"



  • Hmm.. tried with S-3, no change.

    I compared the bed.g files that I have got from different sources and both have S3.
    Ratrig has also V-Core Pro zipped config files available, https://drive.google.com/drive/folders/1_7yTf3TPDbRCY7RIkf1loajXAJYhjxzX
    the bed.g is identical to mine.



  • @Tanel_76 Strange, I nowhere found S3. But too bad that is was not the reason...



  • Did some tests this morning.

    Appears, that the BLTouch is working. I homed X and Y,
    punched in M280 P0 S10 to deploy BLTouch and then
    M564 S0 H0 and started to raise the bed manually.
    While it was moving upwards, I pushed the BLTouch
    nozzle in and the bed stopped. So, it should be operational.

    I found, that I have a wiring related problem.
    While the X and Y homing work as it should, (the printhead
    moves to the left bottom corner, towards the motors
    and then to the center for probing), then when manually moving X and Y
    I see, that Y is moving properly, X is reversed.

    When I reverse the X in config.g, some strange things happen.
    After direction change, the X and Y change places, when moving X,
    Y starts to move and vice versa. Also two Z motors behave erratically,
    after the direction change in config.g

    I mapped and connected the motors differently, X0 Y1 Z2 Z3 Z4 this time and the
    X works correctly and the Y is reversed. After changing Y direction in config.g,
    X-axis starts to move when homing Y. And X starts to move, when homing Y.
    Z motors are just clicking/vibrating.

    All my motors are connected according to the Duet wiring schematics,
    X, Y are LDO-42STH47-2504AC (https://drive.google.com/file/d/1UDBD8BTQWq4__84nZrEikKAiVsDGqI-3/view) and Z motors are
    ACT 17HS4417 (https://www.openimpulse.com/blog/wp-content/uploads/wpsc/downloadables/42BYGHW609-Stepper-Motor-Datasheet1.pdf)
    20200607_112514.jpg

    So, I suspect, I have a wiring related issue, that generates these
    anomalities.



  • @Tanel_76 My first thought when reading your description was to check whether the config has the correct printer type set. I read in
    https://duet3d.dozuki.com/Wiki/Gcode#Section_M667_Select_CoreXY_or_related_mode
    that M667 is deprecated and M669 better be used, and there are different CoreXY types. Maybe it is a wrong one selected. To be really sure you have the correct wiring, you can use G1 H2 movements with single motors selected and verify every stepper and axis.



  • OK, changed the M667 S1 to M669 K1, no change. phfff.

    On the COREXY related page I read, that In firmware 1.19 and later, forward movement of the Y motor moves the head in the +X and -Y directions.
    So, apparently it should move to the opposite direction.

    I'm not sure, why I should start meddling with the movement coefficient matrices suddenly, when similar setups with the same movement logic and even the same motors do not require that.

    I've been trying to generate new config files via Reprap configurator, but no matter what I do, I get the
    "Invalid I/O Mapping, Your configuration contains errors.
    Check the I/O Mapping page before you continue. " error.

    I've been using the Ratrig json and also started from zero, using empty custom template - still the same issue.
    config.json

    What I would like to accomplish now:

    1. Generate a new, complete set of setup files,
    2. Update firmware to 3.1.1 (this is a separate topic on it's own, the 3.0-beta12 the board shipped with, had some issues - the board will not accept the 3.1.1 firmware via USB/Bossa. Pi is updated and I went through the usual procedure, I think twice, the Duet 3 firmware will just will not update and stays on 3.01-RC5)

    Maybe after that the homing issue will resolve.

    I must say, compared to Marlin setups, this is somewhat more difficult.
    Especially the depreciated commands.. I did not expect that 😰
    Gotta chew though the initial set-up hiccups, I really like the web interface
    and the Duet 3 is a fantastic board!



  • @Tanel_76 I fear that you must "fight through" a bit yourself, helping from distance is difficult.

    At CoreXY it is helpful to be aware that your stepper motors and the world coordinates are different things:
    The steppers for the XY movement are sometimes called steppers A and B, which is better IMHO. They create the XY movement together. It is explained good e.g. at https://reprap.org/forum/read.php?2,795060 in the reference2.png left picture.

    First equation: if you want to move X only, you have to move stepper A and B in the same direction.
    Second equation: if you want to move into Y direction, you have to move stepper A and stepper B, but B in different direction.
    Third and fourth equations are from the view of the steppers.

    But in the documents, the steppers are sometimes called X and Y, which produces confusion. You must always ask your self, whether X means the stepper A or coordinate X.

    I hope you saved your old config. I would start from there and check the stepper A, B, Z movements for correctness first with the G1 H2 commands.



  • Hi, thanks for the help.
    I really appreciate it.

    And yes, you are correct, I'm reading through the pages again to see, have I missed something.

    PS. G1 H0 movements were correct.



  • @Tanel_76 Sounds like you need to verify the correct direction of the X and Y steppers. Check this.

    Also, it might be easier to first get the board running in standalone mode (without the Pi). I use the Duet3 in standalone and haven’t found it’s missing any features. Once you have the config correct in standalone, you can the try to tackle the hurdles real with SBC mode.



  • @mwolter The link is a good hint, but it mentions H1 S1 and S2 moves and in RRF3 the S parameter in the G1 G-Code changed to H.


Log in to reply