@deckingman that would also work

@maxgyver it has not

@yao Bump!

Definitely think this is a good idea! I have my printers in the garage, so have a Panel Due for inteacting with them in there, but tend to 'monitor' them via DWC from the house. Currently I have resorted to using a 'tuned' move which hits the midband resonance of the steppers to make a short tune which can usually be heard from afar, but this does feel a bit janky... 😛

This might also appease some of the comments that the small PanelDue buzzer isn't loud enough for their needs

@jos_mosa in RRF 3.4.x a driver-stall event is generated instead, and the driver number is passed as a parameter to the event handler macro. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events.

@benecito said in Improve / optimize PT100 temperatures:

Sorry if I have to ask again, but wouldn't it be much easier vor everyone to be able to tune the temperatures by applying an actual offset instead of fiddling with ADC offsets or resistor values?

If there is an error in the reading, then the best way to correct it depends on the nature of the error. If the reference resistor isn't quite the right value, or the PT100 element isn't quite the right value, then adjusting the R parameter is the correct solution; because adding an offset would lead to reading errors at higher temperatures.

@jay_s_uk correct, I plan to support per-axis idle current percentage in RRF 3.5.

@tom33 This? https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#moveextrudersfilament

I would also appreciate support for the ADXL345.

@droftarts yes, I am aware we have it for deltas.
I think an expansion to match Marlin would be a good addition

I just got my build environment set up. I will be busy at work this week, probably will start my experiments over the weekend.

The first experiment would be hardcoding the E jerk during MatchSpeeds to some small value and see how bridges behaves.
(The jerk value can't be zero due to FP errors. Something like 0.01 is probably more reasonable. I feel MinimumJerk==0.1 may still be high for extruders.)

I still haven't think through what a better jerk policy should be. Allowing the total speed to mismatch between two moves doesn't feel right either because multiple rapid small moves could rack up a lot of speed change in small amount of time.

On the other hand, what's so different with the policy we have today? With the current jerk policy you can make a lot of small moves to form very small turn radius, effectively bypassing the acceleration limit. For example, Gyroid infills are notoriously demanding for acceleration. I suspect we are actually able to cheat by breaking down curves to multiple small moves, by setting "Slicing --> Filtering --> Internal resolution" smaller in the slicer.

An idea I have in mind is to maintain a "jerk potential" which is recharged at the rate of acceleration while capped at the jerk maximum. Once the jerk potential is depleted no more instantaneous speed change is allowed.

@fcwilt 🤣

@jay_s_uk I've added this to the wishlist for RRF 3.5. I'm not sure yet whether to increase it to 24 or make it fully flexible.

@phaedrux said in M568 for other heaters:

This was your thread even 🙂

https://forum.duet3d.com/topic/21649/command-to-turn-heaters-active-standby-off

Bear with me, good sir, I turned 72 this past May and remembering is a slowly fading skill. 😉

Frederick

@jos_mosa No, there is no failsafe for "stupid" moves; on another machine, such a move may be perfectly valid. Generally tools are free to move around in the space defined by M208, once homed. On IDEX machines, you usually set each carriage up as a separate tool, and one gets parked while the other is printing. You can also set them up for simultaneous 'duplicate' and 'mirror' mode printing. In these modes you usually set them to use half the bed area each (and possibly less in mirror mode) so the carriages don't crash. See https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_IDEX#configuring-tools

We are working on separate gcode streams for RRF, so it's possible that each carriage could move independently (though they will always have to be synchronised in Y), but it would still be advisable to limit the print area of each tool to half the bed.

Ian

@dc42 said in Suggestion for a simpler, less error prone, way of bed levelling:

Perhaps it would be better to probe 4 points, at the mid point of each edge of the reachable area of the bed?

Exactly so.

@dc42 That's cool, since my request was about idle extruder motors and their parking axis' motors. IDEXYUV, like my hashprinter