New COREXY printer with Duet 3 issues

Tanel_76

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

mwolter

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

Tanel_76

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

JoergS5

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

dc42

@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

Tanel_76

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.

JoergS5

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

JoergS5

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

Tanel_76

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

JoergS5

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

JoergS5

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

Tanel_76

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.

JoergS5

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

Tanel_76

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

JoergS5

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

JoergS5

@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)"

Tanel_76

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.

JoergS5

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

Tanel_76

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)

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

JoergS5

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