@dc42 You know better than I do. I thought the processor in the PanelDue and the amount of RAM available made implementing sorting there impractical

@cncmodeller That's a good tip, I have actually resorted to something similar!
I created a "M2001.g" file in the sys folder and added a M2001 command on each layer change...

The issue is that I am using a custom slicer that I can't easily change myself and that doesn't have this capability (that at least adds ";LAYER: ##" markers at the beginning of a new layer). I was hoping to not have to manually change the gcode file, but thank god for the "change all occurrences" function in VSCode 🙂

@jay_s_uk Ah perfect, thanks!

@phaedrux Thanks. Perhaps we can hope that this feature will eventually come in the majority of slicers.

I noted that this had also been proposed for Klipper, but never implemented.

I suppose you could remap the toolfan to a new fan number and control it manually. The slicer fan commands wouldn't do anything anymore. But that would only get you a fixed manually set fan speed, not one that scales with slicer commands.

DWC used to have (still does maybe?) a pin next to the fan speed slider for the tool that would let you fix the speed, but it was only active while the DWC window was open. I'm not sure if it's still there or not. I rarely look at DWC at all in my workflow.

@owend there isn't a public one yet. We had planned to move issues and feature requests to github by now, but for various reasons that hasn't happened yet. This is a list of the main features we currently plan for RRF 3.5:

Combine Move and DDA debug in M111 using the bit map
Support for displaying thumbnail images (if not completed in 3.4)
Support two concurrent GCode streams
Axis backlash compensation
M571 when using a remote extruder
Support stall homing on expansion boards
M291 support multiple choice
Support input shaping on EXP3HC
Support input shaping on EXP1XD if possible (may hit performance issues)
Support input shaping on EXP1HCL
Support filament runout sensors (not filament monitors) attached to main board for extruders on tool/expansion boards

Other feature requests will be considered too, such as array-values variables.

@bot I'd imagine it is easier (and more flexible) to reslice with a different parameter (serial number or similar), than it is to dynamically replace portions of existing gcode and handling it on the µC. Especially if the printer is running via an SBC that has more than enough compute power for slicing.

@apak any word on whether or not this is functioning correctly? I would like to set this up for a reverse Bowden setup also.

@gloomyandy
Yes I've read that thread. It retriggered my interest in laser-stuff, which was gone due to diode laser issues.
If I understood the second video correctly, their ppi is directly connected to the (X-)stepper pulses. E.g. at 500ppi every other stepper pulse also fires the laser. That's equally simple and elegant, IMHO.
No need for extra timer routines etc.

@owend thanks for the suggestion. This will be in 3.4.0RC1.

@mintytrebor Did not know that was a thing. Thank you!

@alex-cr Hi Alex - I've used triggers but since going from RRF3.3 to RRF3.4beta7 there seems to be an issue with resuming. I think something as safety critical as an interlock should be defined by it's own gcode. It's just a suggestion, as some workflows seems to be overlooked.

For example using M291 S3 command in a start.g file doesn't cancel the job about to commence if the message is cancelled.

@dougal1957 Sure, using a low standby temperature as a substitute for turning the heater off will do the trick in most situations. However, I can think of a few corner cases where going to the actual off-state may be preferred:

If I do not want to overwrite the standby-temp, for example to make it easy to manually switch it on again To make it clear in the web interface that the heater is off To ensure that the heater does not start even if the temp-sensor says it is below zero.

Note that it is already possible to turn the heater off with "M140 S-274". My suggestion is simply to move this functionality to M144 where it (in my opinion) belongs, since M144 is all about switching the bed heater state.

/Ö

thank you 🙂

Not currently possible. I will move to the firmware wishlist category.

Theoretically it's possible to write a utility program that will takes readings from arbitrary points and will export it as a grid compatible with RRF.

What this utility needs to do is to take the set of points, perform regression to some surface, then sample that surface at grid points and exports the grid to RRF as a .csv file.

If somebody here has a good mathematical background with this sort of things, I don't think it would be too difficult to write.

Alternatively, the program can take a dense mesh sampling with problematic points removed and then estimate them using neighboring points. Again, will require some mathematics.