Thanks, I'll fix it in the next DSF version. If you encounter more issues with DSF, please report them at GitHub.

@dc42 said:

These are awaiting implementation in DSF. M37 is due to be implemented shortly. @chrishamm may be able to provide further details.

I must have misunderstood.
Ah well, I'll just chuck away the last 7 hours of work.

And this is why I said...

it's hard to (contribute) without knowing whether you want them implemented in RRF or DSF or both, and what you already have in the works for the model

@dc42 said in Fourth Extruder not working on latest RRF3:

I've just fixed this - new binary in same place as before.

Tested with the dropbox binary. Now it's working. Thanks

@deckingman So long as the forum can handle the huge file size of your config.g, go for it! I'm sure they would be educational.

Ian

@too said in M28 not working in RRF3:

@dc42 did you get any further on the DSF M28 issue?

I'm waiting for @chrishamm to look into it.

I assumed so, but better for clarification.
Thank you so much for the time and help.

All, please either use DWC 1.22.6 with 2.05RC1, or wait for 2.05RC2.

@dc42 said in M574 usage on RRF 3:

Thanks for reporting this. S0 is handled correctly for endstops on Duet 3 expansion boards, but S0 is currently treated the same as S1 for endstop switches connected to a main board. I will fix this in the next release.

There is a new build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 which should fix this. It also fixes file upload issues when running in standalone mode.

@Veti said in Firmware 2.05 in preparation:

Bed compensation did not take account of the XY offset of the printing nozzle from the head reference point

does that refer to the offset specified with G10 ?

Yes, the tool offset specified with G10.

Thanks, I'll fix that.

@dc42 It looks like that build fixed it.

@dc42 said in RRF3 Sensorless Homing issue/bug:

Now fixed.

Now I'm in a reboot loop. I', going to start a separate thread for this.

And in your spare time you fly 5 T-Rex's...heh heh. Is there no limit to your robopsychosis?

@dc42 said in RepRapFirmware 2.04RC4 released:

@Adrian52, thanks for your report. Looks like output buffers are still being lost somewhere. I will look into it.

Hello!
I want to write about buffer overflow problems.
I looked at the code of the program OutputMemory.cpp
I saw that each buffer has a time of its creation whenQueued.
And there is a GetAge function to see the age of a busy buffer.
You must make the M122 command show Used output buffers and show GetAge age for each buffer.
Maybe then it will become clear in which cases these buffers accumulate and how to fix it 🙂

@gtj0 said in Duet 3: Two or more M122 in a macro crashes firmware.:

@Danal I just saw this in your log...

[warn] Kernel SPI buffer size is smaller than RepRapFirmware buffer size (4096 configured vs 8192 required)

Create a file /etc/modprobe.d/spidev.conf with one line in it...

options spidev bufsiz=8192

The reboot the Pi and test again.

This fixed it.

I found that in the setup instructions last night. I don't remember that being there a few weeks back when I first set up the D3. Could be wrong...

Anyway, it definitely fixes the problem.

@chrishamm said in There's no confirmation after an expansion board flash:

Updating

Not if you're doing it from the console. Like I said, it's low priority.

The oldest log I can find with journalctl -u duetcontrolserver is after that crash. If it occurs again, I'll immediately capture that log.

@pipersw This should work. Though for type drivers the P parameter is ignored and can be left out.

Well, I can't find a combination of commits across projects that will compile so don't worry about it. It was a minor nit and I can work around it easily.

@Nuramori, did you mean to have a G1 H3 command?