CoreXY, Y endstop and homing not functioning properly

tdm418 · 9 Sept 2019, 02:25

First, thank you for your response.
The comment is wrong, it is configured by the S1 as an active high. I have played with that setting in an attempt to find out what is going on, so that is just an old comment that I didn't update. In fact, the first endstop that I used was an active low, and the behavior of the axis was the same.

Phaedrux · 9 Sept 2019, 02:34

If you send M574 by itself in the gcode console, what does it reply with?

If you trigger the endstop with your finger before the head actually makes contact does it stop?

Can you confirm that the 0,0 origin point is at the front left of the printer? X+ moves to the right and Y+ moves towards the back?

Could you post your other homing files as well?

This is on firmware 2.0.3 I take it?

tdm418 · 9 Sept 2019, 03:28

Thank you too, this has been a bit frustrating. I primarily work out of state, so I get very little time, and even less uninterrupted time, to build/test/troubleshoot this thing. Going on 8 months of a couple days every two months.

And this is actually 2.04RC1

Console Reply:

8:09:49 PM
M574
Endstop configuration: X: low end active low, Y: low end active low, Z: low end active low

That is really odd, as the config.g file calls out that the y axis is a 2, which is high end.

Manually hitting the microswitch stops the carriage, but it does not bounce back and then retrigger the switch as it's supposed to. Maybe explained by the confusion about low/high? And the Z axis still crashes into the frame, running right through it's own endstop.

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v2.0.3 on Sat Sep 07 2019 15:25:55 GMT-0700 (Mountain Standard Time)
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 Z-285 F1800 ; move Z down until the endstop is triggered
G92 Z0 ; set Z position to axis minimum (you may want to adjust this)

; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 S2 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning

; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v2.0.3 on Sat Sep 07 2019 15:25:55 GMT-0700 (Mountain Standard Time)
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 X-305 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G1 S1 X-305 F360 ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 S2 ; lower Z again
G90 ; absolute positioning

I do not use the homeall (yet).

Phaedrux · 9 Sept 2019, 04:10

Try putting the endstop config all on the same line. Delete the entire endstop section and retype it from scratch.

M574 X1 Y2 Z1 S1

X at low end, Y at high end, Z and low end, all active high switches.

At what point exactly is the Z axis crashing into the frame?

Endstops are only detected when the G1 move has the S1/H1 switch. S2 allows movement without being homed.

tdm418 · 9 Sept 2019, 04:34

OK, changed the code as you suggested.
No change in behavior, and the M574 command still does not recognize the Y2 parameter:

; Endstops
M574 X1 Y2 Z1 S1 ;X low end, Y high end, Z low end, all active high

9:21:47 PM
M574
Endstop configuration: X: low end active low, Y: low end active low, Z: low end active low

The Z axis endstop is at the minimum, so physically the highest point that the table can travel. (I know that you know this, this is for me to think it out).
So when Z is homed, it first retracts a bit (goes down), then travels up until it triggers the stop.

When the Y axis is homed, it starts by raising the Z axis. The default raise value is 5, and if the table is down less than 5, it raises the table 5, or until it runs into the frame. This occurs whether the Z axis is homes or not. And the Z axis does home itself fine, and motion control is fine once it is homes. Only the Y homing seems to screw it up.

And another interesting problem. The Z axis moves about 5 cm, not 5 mm, when it either homes or I manually control it. Maybe this is correct, but since the X and Y seem to move in mm, shouldn't the Z as well? And modifying the steps per mm in the config file does not seem to affect it at all.

tdm418 · 9 Sept 2019, 04:35

Sorry, substitute "homed" for "homes" in the above.

Phaedrux · 9 Sept 2019, 04:39

Something seems very strange here indeed.

Can you upload your actual files rather than copy and paste?

What does your folder structure look like on the SD card?

tdm418 · 9 Sept 2019, 04:48

Here are the files:
0_1568004240172_config.g
0_1568004266584_homex.g 0_1568004272088_homey.g 0_1568004279822_homez.g

Not sure what you mean by the folder structure, maybe this helps?

Thank you again, especially given the time where you are, this is awesome!!!

Phaedrux · 9 Sept 2019, 04:51

As I suspected...

Your config files are fine, they just aren't in the right place. You've got them in the g-code folder where you would put sliced gcode files for printing. All the config files must go in the /sys folder.

At this point it may be easiest to pull the SD card and use a PC to move the files over. Then to access the /sys folder and your config files with the DWC you use the Settings tab on the left side and then go to the system editor tab.

https://duet3d.dozuki.com/Wiki/Duet_Web_Control_Manual#Section_System_Editor

tdm418 · 9 Sept 2019, 05:07

That certainly took care of the Z axis scaling issue.
The other axis don't want to home, but I'll work on that tomorrow. I suspect that it now is in the code and easily resolved.
Thank you very much for your time and patience. Sorry for such an amateur mistake.

Phaedrux · 9 Sept 2019, 05:24

You're not the first person to make that mistake. It happens.

I think you're well on your way though, the rest of the config looked ok. With the files in the right place it should be a lot easier to figure out what is going on now since the machine should respond as expected.

Any further issues should be easy to resolve.