Timeout after nozzle tip cal

[Common Spotted Cuscus]

Hi People,

I'm setting up openpnp on my machine built out of wet noodles. I'm trying to be self-sufficient as much as possible, including modifying the motion controller firmware etc, but I got stuck on this one.

After nozzle tip cal when the offsets are determined the machine makes a minute move in XY as well as bringing the rotation to 180. This move with the short distance and low acceleration times out. 
At such low speed and acceleration the rotation takes forever so no wonder. Question is that where in the motion setup I went wrong and how to decouple the C axis speed/acceleration from the X/Y/Z.

I'm perfectly fine blaming this on my choice to use grblhal, but nevertheless I'd like to fix it.

If I set motion control type to ToolpathFeedRate I don't have this problem.
Normally I'd be in ModaratedConstantAcceleration, but even ConstantAcceleration mode behaves similarly.


From the log:

Last successful XY move:
2025-11-08 13:48:24.816 GcodeDriver DEBUG: [SKRPico:COM6] >> M204 S12 G1 X61.55 Y317.89   F98 ; move to target, 15000

One successful Z move after:
2025-11-08 13:48:25.221 GcodeDriver DEBUG: [SKRPico:COM6] >> M204 S73 G1   Z-19.400  F2194 ; move to target, 15000

Then a bunch of rotations and camera captrues.
Finally when done and the offsets are determined there is this move:

2025-11-08 13:48:33.235 GcodeDriver DEBUG: [SKRPico:COM6] >> M204 S1 G1 X61.51   A180 F60 ; move to target, 15000

Any pointers?
Thanks!

[Common Spotted Cuscus]

Never mind, AsyncGcodeDriver solved it.
The rotate to 180 is now a separate command with its own feedrate.

2025-11-08 16:09:34.364 GcodeAsyncDriver DEBUG: [SKRPico:COM6] commandQueue offer >> M204 S104 G1    A180 F3680 ; move to target

2025-11-08 16:09:34.365 GcodeAsyncDriver DEBUG: [SKRPico:COM6] commandQueue offer >> M204 S10 G1 X61.45 Y317.98   F62 ; move to target

Is this reasonable or should I be looking for some further underlying cause that otherwise will haunt me later?

Thanks!

[Common Spotted Cuscus]

Well, never mind, the never mind.

Messing around with other stuff and the same problem is still present.

2025-11-08 18:27:41.414 ReferenceNozzleTipCalibration DEBUG: Background calibration computation time: 1.5389749000314623s
2025-11-08 18:27:41.414 AbstractHeadMountable DEBUG: N.moveToSafeZ(0.39)
2025-11-08 18:27:41.414 AbstractHeadMountable DEBUG: N.moveTo((61.419091, 317.733995, -0.800000, 180.000000 mm), 0.39)
2025-11-08 18:27:41.415 ContactProbeNozzle TRACE: N.toHeadLocation((61.419091, 317.733995, -1.000000, 180.000000 mm), ...) Z offset 0.200mm
2025-11-08 18:27:41.415 ReferenceNozzle TRACE: N.toHeadLocation((61.464852, 317.714933, -1.000000, 180.000000 mm), ...) runout compensation (-0.045761, 0.019062, 0.000000, 0.000000 mm)
2025-11-08 18:27:41.416 GcodeAsyncDriver DEBUG: [SKRPico:COM6] commandQueue offer >> M204 S1 G1  Y317.91  A180 F60 ; move to target

After the nozzle cal it is doing a move that includes rotating the nozzle from 144 to 180 with F60 feed and S1 acceleration.
It doesn't time out because of the async driver, but it still takes forever.

What am I screwing up?
Oh, I updated to the current 2.5 test release from 2.4 since.

Thanks,
CSC

[Common Spotted Cuscus]

Provisionally never mind the never mind of earlier never mind.
I'll stop for today, promise.

Machine Axes · openpnp/openpnp Wiki · GitHub
Switch Linear ↔ Rotational 
" If this is not configured right, you typically get timeout errors, i.e. your speed control is not working right, moves are excruciatingly slow or too fast even when you reduce Speed %. Both problems will only occur in mixed moves, i.e. when both rotational and linear axes are displaced in the same move. This typically happens in Nozzle tip calibration.  "