@OwenD

Yeah - this cool idea of RRF having a data-set for the filaments can be taken further!

+1

Vals in filament-config.g of the set filament, of course have to be loaded before the un-/load.g so to be already used e.g. via conditional g-code what is in there... also chamber temperature could be included in the filament-config.g...(also for un-/load.g heat-plate and chamber are not called there within as only the extruder-settings are needed)

@dc42 said in Firmware "wish" - ref the "C" parameter in M581:

@deckingman said in Firmware "wish" - ref the "C" parameter in M581:

@dc42 said in Firmware "wish" - ref the "C" parameter in M581:

@deckingman, see the release notes for firmware 3.2beta1 at https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.

Well I'll be damned!

M581 trigger condition parameter now supports a new value R2 which means trigger only if not printing from SD card.

Looks like you beat me to it. Out of curiosity, why "R2" and not "C2" and do/will C0 and C1 still work as before?

Because M581 also allows triggering on endstop switches, so the C parameter refers to the endstop switch for the C axis. C0 and C1 no longer work as before.

Apologies - I completely forgot that "C" had been change to "R" in 3.1. Just checked my config.g and I have indeed made those changes so I must have known about it earlier.

more background here:
https://forum.duet3d.com/topic/16304/i2c-communication-with-either-the-duet3-or-hopefully/11

It is not a problem but an observation which I have been pondering. Typically, I slice thin layers with a wide paving width using cooler filament temperatures. Recently I Increased the layer thickness to reduce the print time which resulted in a failed print. The surprising and odd bit was the first several layers went down just fine. The thermal mass of the heater block provided lots of extrusion capability at the start but the PID servo loop was not able to keep up. Well it did catch up after the filament was ground free in the extruder and the print failed. I have done PID extruder tuning and the thermal control loop is responsive and seems critically damped but with a slow time constant. Adding the filament E steps would be and instantaneous prediction of a future pending extruder temperature change. Fuzzy logic is a very simple form of artificial intelligence that learns on the job and it is good for controlling nonlinear systems.

+1(000) 😉 I justed asked in the forum if there are any future plans.

Starting from software version 3.2 (currently still beta) you'll be able to browse the object model using a DWC plugin.

I think what you're looking for is move.extruders[0].filament.

@droftarts said in show and connect to available SSIDs through paneldue:

@dc42 could M557 show available Wi-Fi networks (plus signal strength) as well as remembered?

Ian

We would need to have a separate command (M552 S3?) to do a network scan and then return the results. It involves changes to the wifi server firmware as well as RRF (and PanelDue if you want to display it there). I'll add it to the work list.

@OBum_2020 said in M557 number of probe points:

RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later

That's quite old firmware. You may wish to update to firmware 2.05.1 and DWC 2.0.7.

The easiest way is to simply upload this zip file as is (don't extract it) to the /sys folder via DWC.

https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip

https://github.com/Duet3D/RepRapFirmware/blob/dev/WHATS_NEW.md

See the release notes for all that has changed in between, you may need to make a few changes to the config files. This would put you on good footing for the eventual upgrade to RRF3.

I have moved this to the firmware wishlist.

@code7 in short, no not part way through a single long move. but if the long move was splitup then you can insert the feedrate change between the short moves where you want it.

@osterac said in Automatic tilt correction of bed mesh:

The G29 J parameter does this:

I believe this is on the wish list for implementation already.

I have moved this to the firmware wishlist.

@arhi sorry for leading you astray. I said he was on the right track not that everything he said was 100% going to happen. All I was confirming was that the config tool is planned to become more flexible.

Thanks for pointing this out. I have changed it to 'Q' for 3.2beta2, although 'F' will still be accepted for a few versions.

@adarshsimon said in Allow slower minimum movement speed:

@bot "two moves of a print movement" means two axis have to move or two movement commands of a single axis would do?. Thanks in advance.

If you did two consecutive printing commands along the same axis but at different speeds, jerk would be applied between them, even though it could be avoided.

@dc42 For sure startup (in terms of getting all values refreshed and initilized). I would need to measure how fast it reacts, as I observed it takes some time between selecting tool and actual confirmation in color change.