Topics created by Merlin246

@Merlin246 I'm glad you solved it. Nesting tool changes is never a good idea. Perhaps we should detect that in RRF and report an error.

@Merlin246 unless you are trying to detect motor stalls at other times too, you need only use M915 in config.g.

If you are trying to detect stalls at other times too (so that you need two different sets of stall settings), you can use global variables to save repeating the values and make them easier to change. For example, in config.g:

global normalStallSettingX=3 global homingStallSettingX=1

then in homex.g, homey.g and homeall.g:

M915 H200 X S{homingStallSettingX} R0 F0 ... do the homing M915 H200 X S{normalStallSettingX} R0 F0

Similarly for the Y motor.

@Merlin246 currently it's possible in RRF 3.5.0beta but cumbersome, like this:

M92 E{move.extruders[0].stepsPerMm, 405, move.extruders[2].stepsPerMm. move.extruders[3].stepsPerMm}

However, you could build a macro file based on this command to make it easier.

Yes, you configure firmware retraction with M207

https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m207-set-retract-length

The slicer must be set to use firmware retraction as well, so that when a retraction is needed the slicer inserts a G10/G11 command.

To configure retraction for each tool, you can add an M207 command to your tool change files custom for each tool.

This also means that retraction state is tracked by the firmware, and it will un-retract when needed before starting to extrude.

@Exerqtor awesome thanks!!

@Merlin246 said in [REQUEST] Smooth Bed Mesh Movements:

most likely as the z-motor cannot keep up with the requirement for the mesh bed.

Your Z axis jerk value is probably too low. This is a common side effect.

@Merlin246 You probably haven't set up PrusaSlicer correctly. DWC (or precisely) RRF/DSF detect the current and maximum layer number from G-code comments and they fall back to the Z/layer height if that info isn't present. You should have this in your after layer change G-code ;LAYER [layer_num] and this at the end of your custom end G-code ;NUM_LAYERS [layer_num]. Then you should see the correct layer numbers. As @deckingman said, support layers are counted as separate layers - at least in PrusaSlicer.

@Merlin246
You could do it with M291 and a loop.
Here is an extract from a macro I use to preheat for the current filament
The down side is that the user can't do anything while the message box is displayed, so if something is wrong an e-stop may be required.

var TargetTemp = heat.coldExtrudeTemperature+10 var thisHeater = tools[state.currentTool].heaters[0] ;show progress of heating from lower temp while (heat.heaters[tools[state.currentTool].heaters[0]].current) < (var.TargetTemp - 2) M291 R"Preheating.. Please wait" P{"Current temp = " ^ heat.heaters[{var.thisHeater}].current ^ " : target = " ^ (var.TargetTemp) } S0 T2 G4 S1.8 if global.Cancelled = true M108 M98 P"0:/macros/heating/all_heaters_off.g" abort "heating cancelled" ;show progress of cooling from hotter temp if (heat.heaters[{var.thisHeater}].current) > (var.TargetTemp + 1) echo "Fan on to help cooling faster" M106 S1 while (heat.heaters[{var.thisHeater}].current) > (var.TargetTemp + 2) M291 R"Preheating.. Please wait" P{"Current temp = " ^ heat.heaters[{var.thisHeater}].current ^ " : target = " ^ (var.TargetTemp)} S0 T2 G4 S1.8 if global.Cancelled = true M108 M98 P"0:/macros/heating/all_heaters_off.g" abort "heating cancelled" echo "nozzle temp done" M106 S0 ; part fan off

@dc42 on the topic of the patent, as I'm working on a tool changer myself, is it this particular one or something else? https://patents.google.com/patent/US8926484B1/en

This one seems to cover most aspects of tool changing and I wonder how E3D and Prusa managed to work around it. Or perhaps there's a different patent? I read that not transferring power from the gantry to the tool might avoid the patent, but am not sure.

My solution transfers power to the heater via POGO pins, and reads the thermistor. Wondering if moving these specific wires outside the gantry would not infringe. Still not sure how to do this for 14 hotends though.

@achrn it does! Thanks for the suggestion, going to be using this from now on 😄

@Merlin246 ok agreed, will move this to the firmware wishlist for future considerations.

@dc42 so I moved the printer closer to the access point, it now reports -49dBm and I have no issues with uploading (also just upgraded to 3.4.5, but that happened after the uploading issue was resolved already in 3.4.3 by moving closer to the access point) . However it is in a more office-y area which is not great for noise (was previously in an isolated room).

It appears it has nothing to do with the firmware, however I still find it strange that the WiFi strength at -65dBm (admittedly, not the strongest) caused upload errors. I can down-grade and move it back to the other area as a test if you are still interested in having that tested.

@achrn No need to be sorry. BTW, after thinking about it, there’s a real use case when you specify filament directories: there, you can provide multiple (partial) config.g files.

It's likely that you just need to adjust your Z jerk setting to be a bit higher.

@dc42 in DWC, the time remaining counter derived from slicer print time estimate starts when you start the print and heater time is included.

@Merlin246 said in Setting global variable positions... pls god help:

Is there a way to denote using periods instead?

No.

@Merlin246 it just hasn't been implemented in the expansion board code yet. i believe there was talk of adding it to 3.5 IIRC

@Merlin246 here are some possible workarounds:

Reduce the overshoot by increasing the M307 R parameter. This will only help if the bed surface temperature overshoots. If the temperature sensor is close to the heater and the surface temperature lags the sensor temperature then it may actually make things worse.

Many slicers have the option to wait until the bed is at temperature before they heat the hot end. The hot end heating time may be enough for the bed temperature to stabilise.

Typically, if the slicer sees a heating command in your start GCode, it won't generate the heating command itself. So you should be able to put the bed heating command followed by a G4 delay in your slicer start GCode.

@jay_s_uk thanks for a great suggestion! Will implement ASAP 🙂