Here's what I ended up doinanyone is curious and needs to set up a workbee updgrade kit on a custom machine 🙂

I edited the following files:
homex.g
homey.g
homez.g
homeall.g
and the custom config file with the size of my machine...

@TC said in Filament type assignment:

"state.currentTool

Thanks! I'll look into that. Actually I think after my update to 2.05.1 my filament config.g macros aren't even working. Going to check into that.

@Phaedrux okay, thanks.

@droftarts Yes mate, I have been changing tools recently from single nozzle 1 extruder to single nozzle 2 extruders, to 2 nozzles 2 extruders and diamond 3 extruder, So plently of tool definition changes and I missed the above. At least that's my excuse lol..

No worries think I have sorted, Reset everything, deleted cache and repaired sd card.
Not sure what fixed it.

@bearer said in Step 9 - Check Access to Duet Web Control not working:

@Danal said in Step 9 - Check Access to Duet Web Control not working:

Correct. In fact, there is only one "default gateway" per host (PC) and that should remain untouched, pointing at the spectrum stuff.

Every network interface has a gateway setting; and windows is clever enough to change the default gateway to the most recent interface activated, thus the importance of not setting a gateway for the wired network.

We are saying the same thing.

There can only be one active default gateway in an IP based host. This has nothing to do with windows.

A given (IP V4) host can have multiple interfaces, and it can store multiple configurations for choosing which gateway to use depending on which interfaces are marked "active" (although, it really is defined by which gateways are reachable through local interfaces. An interface being active is only one part of this).

At any given moment in time, when deciding where to send an outbound packet, the destination IP of that packet is masked to the subnet of each local interface, and, if there is a match, it is placed on that interface (in an 'outer wrapper' that is determined by the media type). All of this occurs before the host even 'looks at' the default gateway entry; only when the list of active local interface reachable subnets has been exhausted will the host send the packet to the default gateway (via whichever local interface makes the gateway reachable). Again, this is IP and has nothing to do with Windows per se.

So we are saying the same thing: One active default gateway, in this case, with a subnet that matches the active WiFi interface that points to the provider, and one local subnet, with no gateway on that subnet, that is the hardwired Ether to the printer.

Please connect to the Duet via USB. Then when the problem next occurs, send M122 from USB and post the response here.

By way of further explanation: SD cards are optimised for doing very large block writes. A digital camera captures several hundred Mbytes of data and needs to write it to the SD card rapidly in order to be able to take another shot. So modern SD cards have large RAM buffers to accept the data, then after it has all been received they get on with writing it to flash memory and moving blocks of data around to implement wear levelling. Unfortunately we only have 128Kb RAM total available on the Duet 2 series, so we have to do much smaller block writes. You can use the M122 P104 function (https://duet3d.dozuki.com/Wiki/Gcode#Section_M122_Diagnose) to measure the SD card write speed achieved by the Duet.

@bearer yes. maybe the board had to warm up. got me stumped. i have come across weirder things than that unfortunately.

Is the 2.4GHz WiFi spectrum crowded where you live? I know from personal experience (at an exhibition) then when the spectrum is crowded, changing the WiFi channel can make a lot of difference to a Duet WiFi with internal antenna, even if the signal strength is good. In that instance I used a smartphone app to display all the existing APs in the area and choose a quiet channel.

@droftarts PS. Yeah, I had tried that. Naming the fans made them show up indeed, but the sliders didn't do anything. Upgrading to the current firmware then did the trick.

@bearer Yeah i talked to IT and they don't care about me adding this access point

@bearer

Ok now, replaced the index with the gz un compressed, replaced the htm and html index gz with the reprap gz. Everything back to 1.22

Thanks for the guidance!

@gtj0 said in Overview of implemented Gcode RRF3 for Duet3+Pi:

M500 not working isn't mentioned in the guide. Is that related to the autotune on remote cards not working either?

M500 doesn't work with the DSF/SBC for any heater because we're waiting on @chrishamm to implement support for getting the values from the Duet and writing them to the config-override file. AFAIK it works in standalone mode (at least for local heaters).

I hope @chrishamm remembers to sort G32 not reporting any output and having to enter commands in the console twice before they work!

Aaaaah!! Thank you very much, now it works with RRF3!
Thanks for the support!!

The maximum file path length supported by RRF is 120 characters, including 0:/gcodes/ at the start. I can increase this for Duet 3, but I don't want to increase it for Duet 2 because of RAM constraints.

I doubted that you'd typed those all by hand. Well done.

@Danal
The heater erratic behavior is on the configurator page only at https://configtool.reprapfirmware.org/Mapping
It's perfectly fine on the printer itself! I actually managed to finally get a calibration cube out of it 😄

Thanks for confirming the case of M500.. Yeah 😛 I ended up doing the M307 for H0 and H1 by hand and filling them up there and then doing the M665 and M666 as well. (I'll move them to the config.g since they don't really need to live in the override either.)

So far so good!

I'm all new to RepRapFirmware and coming from old Repetier 8 bit world. 😆

@Danal Awesome! Thank you.

@Phaedrux Ok now I get it. That makes sense. Thanks!