New COREXY printer with Duet 3 issues

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.

Tanel_76

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:

Generate a new, complete set of setup files,
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!

JoergS5

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

Tanel_76

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.

mwolter

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

JoergS5

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

mwolter

@JoergS5 Yes, you are correct, thanks for catching that.

@Tanel_76 The G1 commands In the document I linked, you need to use H instead of S. I still highly recommend using that document, it’s a good overview of the process to verify proper direction of the steppers.

I’m sure this is part of the confusion, most of the documentation was written for RRF2 and hasn’t been updated to work with RRF3 also.