@T3P3Tony - Great advice and Ill be sure to utilize. Since I've never played with the Duet version of an accelerometer, so I'm not sure what all homing it will want to do, but I'm thinking I'll first try with the 1M cable and just activate the end stops if it wants to center in the bed. Just keep the hotend within reach.

@53581 said in diagonal line on print causing layer shifting?:

a add linear bearings for the blue lines and then somehow mount the linear bearing cars to the x in a way that it can pivot so it can move independently.

To avoid axis' binding, you need to fix one side while the other side can "float" in one direction to compensate thermal expansion.

@ironhydroxide said in Having troubles with Closed Loop tuning Plugin:

So I figured I'd practice tuning the motor with only magnetic before "leveling up" to the quadrature and magnetic (M569.1 T1)

Ahh right i did not realise you had a linear encoder on this axis as well. As you say, that's not relevant to the plugin issue.

I have got a test setup now, I note the following:

In the video I see you initially capture, with the plugin, at a speed and acceleration above what is configured in config.g. The moves you sent directly on the command line are much shorter and slower You don't need to clear and re check the encoder calibration unless you change the mounting of the magnet encoder board. (although see below about the calibration values you are getting) Its setup as an extruder. Which i think is the core problem with the plugin - For some reason the plugin does not like tuning it with a step move as an extruder. I need to look at that further, but as a closedloop extruder is not something that people use often that would explain why this has not come up yet.

It does appear to work for me tuning it with a custom gcode move:
82f90ffa-bbe2-452f-a0b2-fdaf6dcca819-image.png

However for now if you remap it as the X axis, and use reasonable values for the step manoeuvre settings then it tunes for me:
17a0b169-c6da-487e-bac5-536ba86a691c-image.png
0ef525a6-462d-426a-893e-a444f409aa85-image.png

I used these values, modified from your config.g:

M584 E0; set axis mapping M584 X123.0; set axis mapping M350 X16 ; configure microstepping M906 X800 ; set axis driver currents M92 X28246.530421 ; configure microsteps per mm M566 X0 P1 ; set maximum instantaneous speed changes (mm/min) M203 X17.7 I0.1 ; set maximum speeds (mm/min) M201 X5462.962963 ; set accelerations (mm/s^2)

And also set X to 0 to avoid homing

G92 X0

Calibration values:
As a point of reference my test rig has the following calibration:

M569.6 P123.0 V2 Driver 123.0 calibration succeeded, measured backlash is 0.020 step Original encoder reading errors: min -28.1, max 29.8, rms 14.1 Corrections made: min -23.2, max 24.8, rms 13.9

You may want to check the magnet is centered, the reported agc value you showed in the video in the M122 report is not bad.

@MurphDurtay said in Printer won't extrude walls of prints.:

Everything seems to be working as usual now with the 0.4mm nozzle. Could I just ratchet up the nozzle temp to like 270 to print with the 0.8 and 1.0mm nozzles?

You can try that, but you may also want to look at https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m309-set-or-report-heater-feedforward.

@damaged_goods You could perhaps trigger a homing move when Z changes, using daemon.g, (assuming you don't use Z lift on travel moves), but a better way to do it is to add a homing move in the layer change Gcode in the slicer. Most slicers can do this nowadays.

Ian

@chrishamm works great! Thanks for the insight.

Below is an excellent guide for more detail.

https://github.com/thagrol/Guides/blob/main/bookworm.pdf

Just as a follow up, I am happy to report that drying the PETG helped quite a bit. While the new print isn't perfect, I can't call it a 'dogs breakfast'. Besides drying the filament, I also went with random seams as all other choices ended up putting the seams on the overhangs.

@zuoyan said in mesh compensation causes dragging of moves:

Do we know the consequence of too high jerk/instantaneous speed change values? Like smoothed corner or lost steps?

You only need to increase the Z axis jerk slightly. 60 to 120 mm/min range. This will have zero effect on XY motion of corners, etc.

Just a brief follow up to this, I never could get a good first layer with this setup. I tried with a bltouch, inductive and IR sensors all gave similar results, the first layer was very inconsistent.
I have now installed a dyze designs horizon z probe which uses the nozzle for z probing, mesh bed compensation now works as expected and I get very good, consistent first layers.

@dc42 said in hierarchy of control over gcodes, machine vs filament vs slicer:

The printer speed and acceleration limits should always be set no higher than the printer can reliably achieve. Otherwise you may end up with the slicer commanding the printer to move faster than it can manage, especially if you use the speed factor control in DWC or PanelDue to increase speed. You can of course set lower speeds and accelerations in the slicer settings.

That's something I have wondered in the past. If the slicer says to move at 100mm/s, and RRF has the speed limit set to 150mm/s, I would expect the printer to move at 100mm/s. If the speed factor control is then set to 200% in DWC, what happens? How fast does RRF drive the printer? 150 or 200mm/s?

I mention speeds, but presumably this applies to accelerations just the same?

I did look in the DWC manual for the speed factor control but it wasn't clear to me what limits were still imposed, if any.

This also had me wondering the other day as I was adjusting pressure advance as well as input shaping. In particular if pressure advance could result in extruder feed rates outside the limits that I had specified in RRF, and if some sort of clipping might occur if hard limits were enforced resulting in some obscure printing artefact. Same with input shaping and how the actual moves sent to move the head might look after going through a 'shaper filter' and whether they too were being 'clipped'. ... I have a background in audio design where clipping is just about the worst thing imaginable for a poor audiophile. 🙂

Now that I'm running two linear delta machines, where the amount the effector moves is not nicely related to the rotation of a single stepper but some combination of all three depending where on the print bed you are, it really starts to do my head in. Plus that's without considering bed mesh correction, tapering, skew adjustment, or others I don't even know about. 🙂

A user submitted a pull request to PrusaSlicer some time ago to fetch the printer speed and acceleration limits from the RRF object model and to modify the print time calculation to better reflect RRF when RRF is the selected firmware type; but unfortunately it wasn't actioned. See https://github.com/prusa3d/PrusaSlicer/pull/8087.

Oh, that's a shame, I for one would have found it useful.

@jay_s_uk
Yes, it's an interesting approach too, because it doesn't use memory by creating global variables.
Thanks for commenting.

@gloomyandy thanks for the update. Appreciate tracking this one down

@dc42 - thanks for the clarification.

@p8blr in that example you would divide your E steps/mm by 1.0036.

The best fit line in the graph in your earlier post showed an intercept of 0.9194 so if using that to provide the parameters you would multiply the steps/mm by 0.9194.