Sharp changes in speed during travel moves on Polar Printer

[o_lampe]

@cncmodeller
You could tell the slicer to 'not cross the object' when travelling. That would usually slow down the print, but in your case it could be faster in the end. Let's hope it'll always take the outer route around the object.

[dc42]

@cncmodeller please supply a GCode file containing travel moves that demonstrate this problem, then I will investigate it. It doesn't need to be a complete print, just enough for me to see this problem happening within no more than a few minutes. It doesn't need to be the first layer of a print because I will run it on my bench setup.

So I've done some basic testing and I think what's happening is as the move comes closer to the centre of the bed, the speed is reduced in steps to maintain max bed rotation speed rather than continuously.

If the travel move is a G1 move then the move will indeed be split up into steps, but those steps will normally be too small to distinguish, controlled by the M669 S and T parameters. However, if you use G0 travel moves then AFAIR they don't move in straight lines when using Polar kinematics, so the head should not pass close to the centre.

[CNCModeller]

@dc42 I'll have a look over the coming days and pull something together as per your request. Unfortunately I'm back at work with the day job now so it'll take me a bit of time to sort out.

Many thanks
Barry M

[CNCModeller]

@dc42, after some concerted tinkering it would appear that @Phaedrux was correct that the issue is only present when mesh compensation is active.

I have progressively increased max z speed and acceleration to values that if much greater start to result in abnormal Z axis behaviour.

I have also increased instantaneous z speed changes (from 50 to 1000 via a few intermediate steps) but I'm not sure how far to go with that as my current test script doesn't actually print (I removed the E commands from the test gcode) I cant see if there is a loss of steps in Z due to high instantaneous changes. However the severity of the "kicks" during travel moves don't seem to be reducing.

These are my config and test code files, the test code is an extract from a single layer of one of my large prints and does display the kicks during travel moves if mesh compensation is active.

config.g
Test3.gcode

Videos:
Mesh
No Mesh

Tapering out mesh compensation with M376 H5 doesn't seem to work, noting that my test file runs at approx. 25mm in Z and still exhibits the kicks with M376 active even when Z doesn't look to be moving at all w.r.t. mesh compensation.

To be honest I'm thinking of just disabling Mesh compensation after its tapered out with G29 S2, e.g. at something like the 10th layer. Can I do that automatically for every print, or do I have to embed it in each GCode file?

As always any thoughts would be much appreciated.

All the best,
Barry M

[Phaedrux]

@cncmodeller said in Sharp changes in speed during travel moves on Polar Printer:

M376 H5

Do you mean to say that with taper set to 5mm it's still hitching above that height and that if you use G29 S2 to completely disable it that it stops the hitching?

[CNCModeller]

@phaedrux said in Sharp changes in speed during travel moves on Polar Printer:

@cncmodeller said in Sharp changes in speed during travel moves on Polar Printer:

M376 H5

Do you mean to say that with taper set to 5mm it's still hitching above that height and that if you use G29 S2 to completely disable it that it stops the hitching?

Yes, that's what I'm experiencing based on my test gcode that just does some representative moves at approx z25.

It's almost like taper just fades out the final delta being added to z but it's still doing the compensation process in the background.

[Phaedrux]

If that's the case then it would seem to be a bug. @dc42?

[dc42]

@cncmodeller thanks for your new data. Please supply the height map file that you were using, or any other height map file that exhibits the same problem with the Test3.gcode file.

[CNCModeller]

@dc42 sorry for the delay in responding been away and busy with work.

This is my current heightmap.

heightmap.csv

I've just run the Test3.gcode file and its giving the snatchy travel moves as before so should be good for testing.

[dc42]

@cncmodeller thanks.

I've run your test3.g file, however I can't tell the difference between running it with and without your height map file loaded. Of course I don't have a real polar printer, so I can only look at the movement of the motors. Also your test3.g file contains a large number of moves, mostly short ones; so I can't tell whether there the amount of jerkiness I see is natural because of direction changes, or unnatural because it is in the middle of a single move.

Your height map shows a bulge near the centre of the bed. If the jerkiness is predominantly when the print head is near the centre, then I think it's most likely that the cause is the need for the Z speed to change significantly when the head passes the centre, coupled with your low value (20) for Z jerk. If that's the case then increasing Z jerk or reducing speed will likely remove the jerkiness - although of course increasing Z jerk too much could leads to skipped Z motor steps.

[CNCModeller]

@dc42 Thanks for looking.

So the jerky nature is only during the travel moves to and from the print location. The small elements of printing in the middle of the file are fine.

You can hear the feature in the mesh and no mesh linked videos earlier in the thread.

The bed is a 600mm mirror clamped at the edge so some of the bed lump is due to that. I'd need to apply a vacuum to pull the centre down. I also think there is an element of my radius arm running lower towards the bed center as it's only supported at one end but I don't have enough fine adjustment to remove what's left. Hence why I am using mesh.

I've tried increased z jerk and speed settings to no avail. See earlier in the thread. Currently I disable mesh in my gcode rather than using the taper function, full disable mesh gets rid of the issue where as mesh taper doesn't.

I don't suppose that I'm running a prototype 1HCL driver on the bed in open loop mode makes any difference?

Anyway thanks for looking. If you have any other thoughts I'd love to hear them.

All the best
Barry M