Topics created by ardenpm

I would also guess maybe putting a G4 P0 after the M98 lines in the test.b file might be instructive. I can imagine the console messages not buffering (are they supposed to buffer?). I might also make testa.g have a parameter that you then echo along with the answer, and have test .g supply a unique value on each m98 call. This would let you see which of teh M98 calls are getting lost (the presumption is it's lat last getting lost, but nice to know for sure).

@deckingman Good question there is another comment in the code...

// 6. Set the speed to the smaller of the requested and maximum speed. // Also enforce a minimum speed of 0.5mm/sec. We need a minimum speed to avoid overflow in the movement calculations.

Which sort of answers your question, but raises the issue of what happens if the speed ends up being reduced below the minimum? Could be an out of date comment, but who knows....

Does your slicer have a place you can enter code during a retraction? Some of them do.

@fcwilt I don't believe PrusaSlicer has custom G-code for retraction.

That would solve the speed problem as you could set the extruder speed to the max for extrusion and in the retraction handler up the speed during retraction and then put it back to normal.

I don't really see doing the above as too big a problem in any case since it's only for these specific priming moves which already have a fairly large amount of Gcode scripting around them, so it's just a few extra lines.

If it can't be done in the firmware, there are hardware modules that do it (used by aeroplane modelers for flaps or undercarriage). Search "servo slow" or "servo speed reducer". About £10 - £15 typically (a few cheaper on ebay).

@ardenpm thanks. I have updated the documentation.

Re-tuned with the tools over the center of the bed. The two Volcano tools both gave me the inconsistent behavior warning this time (where as only one did last time). They gave me:

M307 H3 R1.312 K0.283:0.128 D7.94 E1.35 S1.00 B0 V24.1 M307 H4 R1.396 K0.290:0.166 D7.39 E1.35 S1.00 B0 V24.1

The second part of the K value is still fairly different between the two Volcano tools. At this stage I think I will go with what I have and wait and see if I hit any faults or other issues and come back to this when I have been printing with it more.

@ardenpm yes that diagram is correct.

Just for prosperity if others come across this thread in the future, I finally got around to updating to RRF 3.4.x and the implemented change works great. I can now correctly define the servo with the needed PWM frequency like so:

M950 S0 C”duex.pwm5” Q333

And then move it with the servo commands like so:

M280 P0 S45 ; set servo position to 45 degrees

And it moves a sensible amount as expected.

Thanks for the clarification. While it might be obvious to a hardware person that sharing them would mean the heater and LED also gets enabled, it might be worth adding a note to that effect.

While I had already read all of the linked information, it wasn't clear to me whether software configuring the pins for use as PWM for servos etc does anything special or just tells the firmware how to map them.

That sounds like the right solution. I will try it out when back at my printer. Is there a comprehensive list of all supported system .g files somewhere?

Would that then also solve the issue of homing Z doing the same thing? I would guess so, the only thing I am wondering is whether this works when using the endstop as the probe.