Pause after homing X

lmcbmai

I have Core-XY printer (H-bot) and my homing sequence is - X then Y and finally Z. Most of the times homing works as it should, but in about 20-30% of cases I am observing that print-head homes at X then stops for several seconds (could be up-to 10) and then continues homing towards Y and Z. While this is not causing any problems, I am just curios what could be the reason and whether anybody else is observing similar behavior.

Thanks

Repetier

Do you always move back from end stop so it 100% untriggers? If not it might trigger the delayed sequence also I do not see why. Must be a move that it want to do but where steps are blocked due to end stop triggered, otherwise you would see it.

lmcbmai

Yes, once end-stop is triggered, print-head moves slightly back and then forward again (the same for all 3 axis). If I recall it right, the pause takes place after all moves along X are completed (including back and forth), right before print-head start to move toward Y-home. But I am not 100% positive; I will double check and post the update.

Thanks

lmcbmai

It just happened again. I cancelled the job via Octoprint and then hit Octoprint's Home XY button. Print-head moved to X-home, then paused, then did back and forth movement, as it should, followed by Y-homing.

Here is the extract from Octoprint terminal log

Changing monitoring state from "Cancelling" to "Operational"
[...]
Send: N326 G9122
[...]
Recv: ok 326
Send: N327 G28 X0 Y020
Recv: ok 327
Send: N328 G90*25
[...]
Recv: busy:processing
[...]
Recv: busy:processing

Repetier

Do you have fast corexy enabled? This sounds like he wants to execute the complete move but end stop triggered prevent motor motion. Normally you have one move and it hets canceled and he moves back. With fast corexy the move is split into several moves and only the first is handled correctly and next moves are executed fully without moving then. That explains the delay. But I'd expect it to happen every time rather then only some times. Except if you start from right end and sometimes near left end. If the submoves are already removed from travel only one segment might be left. Therefore for fast corexy you normally reduce computation per second to a minimum (motion is linear anyway). Just big enough that each subsegment has less then 32000 steps. If you have 10 subsegments per line that then allows 320000 steps to be stored which is normally full printer length.

lmcbmai

I was not able to find fast corexy setting in Configuration file, so I searched entire directory for FAST then found FAST_COREXYZ entry. Assuming you are referring to it, I searched entire directory again and got 18 hits shown on the screenshot. I cannot see any place where it is defined; these are all IF statements, so I guess it is not defined.

Thanks

Repetier

Yes, that is the option I meant. If you define it in configuration.h it uses a different solution to move which is faster and does not need the virtual double resolution (which is why it is faster). But it uses the nonlinear handling from delta printers which you need to adjust. One of the main reasons it is not described officially. In the forum or on github you find more about that solution.

But that means you are not using it, so that explanation is not the problem. You are using same homing code as normal cartesian printers.

Since it does not happen so far for me i can not debug the problem. If you have some programming skills you could do. Mainly adding some debug messages to see in log so you see where in code the hang happens. What you could try is
M111 S70
which enables debugging end stops but also can cause firmware to crash so really just for testing. The only thing I see is the first long move that takes time and stops when endstop is triggered. So what is happening - does x endstop get triggered or does y endstop get triggered and x move continues without moving since endstop y also stops x on core xy but does not finish move. So it executes all steps until finished. No harm just wast of time. Might in deed be what is happening in your case so worth to set the debug flag and home a few times. But go back into field before rehoming.

lmcbmai

@Repetier Wow! Lots of good and new information for me and, hopefully, for other readers too. Thanks for your explanations and suggestions.

I do have programming skills, but right now I am in the active phase of building new IDEX printer and my first and so far the only one printer is printing IDEX parts almost 24/7. If this issue does not go away, I may try to debug it, as you suggest, but I don't see that happening any time soon.

Still, I will post updates here, if I obtain additional information.

Thanks again!