Errors during Auto Delta Calibration

JohnOCFII

More info.

I attempted again. Failed in the same way. It failed on a calibration point very near the edge of the glass between the X and Y towers. The LED light on the IR sensor never lights when it fails (where it lit properly on the previous points). I confirmed that the homing errors happen after the firmware restarts after the emergency stop. I attempt to home the printer, and due to the position of the effector, the X and Y carriage reach the endstops at almost exactly the same time, and well before the Z carriage. The system acts as if it is homed before the two carriages back off and wait for the third to home, then the error message appears, but the system does seem to home successfully after that.

I now also wonder if the "Error: Attempt to seek on a non-open file." is also a red-herring as it shows up after I press the Emergency STOP button in the UI.

It would seem the IR sensor stops sensing for some reason. Not sure what to try next.

Thanks,

John

Billhc83

I would move the probing points that seem to be causing problems to see if that rectifies the problem hth

JohnOCFII

@Billhc83:

I would move the probing points that seem to be causing problems to see if that rectifies the problem hth

The probing has failed in three difference places today. It is true that the last 3 failures were on the same point. I could certainly move the probe point, but since the error wasn't always in the same place, I'm not sure if that still will help.

Thanks,

John

Billhc83

Well if the light is not coming on consistently I would think it may be the wiring. Maybe a connection has come loose or possibly one of the IR LEDS has become bent and is not being read properly (this maybe only on the older IR boards I believe David has used different components on the newer ones - I may be mistaken) But this has happened to me with one that I have. I would think wiring though if it has happened in the same part of the bed multiple times - maybe wires are being pulled when reaching the edge of the bed?

dc42

@JohnOCFII:

More info.

I attempted again. Failed in the same way. It failed on a calibration point very near the edge of the glass between the X and Y towers. The LED light on the IR sensor never lights when it fails (where it lit properly on the previous points). I confirmed that the homing errors happen after the firmware restarts after the emergency stop. I attempt to home the printer, and due to the position of the effector, the X and Y carriage reach the endstops at almost exactly the same time, and well before the Z carriage.

If the IR sensor isn't triggering at that point near the edge of the bed, there are a few possibilities:

You are probing too close to the edge so that the sensitive area of the IR sensor is not completely over the bed
There is some difference in the surface of the bed at that point, causing the trigger height to decrease to a value below the height of the seor above the nozzle
Your effector it tilting significantly at that probe point due to geometrical errors, and that tilt is raising the IR sensor relative to the nozzle, so that it never gets close enough to the bed to trigger. Use a bulls-eye spirit level on the effector to check for tilt.

For the homing issue, see #5 at (edited) https://www.duet3d.com/wiki/Common_problems_and_their_solutions.

JohnOCFII

Thanks David. I will check those items. I'll also double check the wiring, as Billhc83 suggests.

As per usual, the main cause for my questioning is that it was working fine not three hours previous. I'm starting to wonder if something mechanical is causing a problem.

I'll have to get a bull-eye spirit level. Seems to be a useful item for a Delta. Anyone have suggestions?

Also - your link regarding the homing issue takes me to a note about someone with power issues. That doesn't seem like the correct link.

Thanks again,

dc42

Sorry, wrong link, should have been https://www.duet3d.com/wiki/Common_problems_and_their_solutions.

JohnOCFII

Thanks David.

Regarding the homing issue, I changed the following line:

[[language]]
G1 X265 Y265 Z265 F2400 S1

to

[[language]]
G1 X270 Y270 Z270 F2400 S1

With no change in behavior.

The printer is a T3P3 V3 Kossel Mini with Duet WiFi.

What I see happening is that this happens when the hot-end is near the edge of the build area centered (or nearly centered) between two towers. When I hit "home" all three carriages begin to rise. Two carriages rise up, hit the endstop, pause for a second, then re-approach the endstops before the third carriage makes it to its endstop. The printer DOES complete the homing routine, but before it does, the "Attempt to move the head of a Delta or SCARA printer before homing the towers" is logged to the console.

I've linked to a photo showing the position of the effector before hitting "Home" and a short video of the homing process.

https://i.imgur.com/9YJ2B2v.jpg

https://youtu.be/SjiHQ7l78TQ

Thanks,

John

dc42

I think 270 is still too small. Place the print head at the edge of the bed, opposite one of the towers. Then measure how far the carriage on that tower has to move up to trigger the endstop. You need to use a value greater than that measurement.

JohnOCFII

@dc42:

I think 270 is still too small. Place the print head at the edge of the bed, opposite one of the towers. Then measure how far the carriage on that tower has to move up to trigger the endstop. You need to use a value greater than that measurement.

Thanks for the detailed explanation. I measured max distance to be about 350. I modified the entries to be 370 and now it works as expected.

[[language]]
G1 X370 Y370 Z370 F2400 S1

Of course, re-reading what is in the Wiki is completely clear to me now.

Thanks - now I can back to troubleshooting the other issue.

John

JohnOCFII

This morning was the first chance I had to try this again.

I realized that I could run G32 from the DWC many times without issue. I ONLY had issues when running it as part of the pre-print calibration as part of a particular print I was trying to do. I regenerated the GCODE from S3D, and that GCODE ran fine, including the G32. I've done a couple of other small prints since then that also worked.

So - either this problem occurred with a bad GCODE file, or gremlins.

I'll consider this resolved.