@chrishamm I isolated the problem to be specific to only one of our machines. So it's not firmware related, the problem is on our end

@JRCL Funmat and Creatbot probably use a modified PEEK that needs annealing. In any case, the best practice is to focus on chamber temperature uniformity before going after high temps.

@Herve_Smith If you compile your own DWC, changing the countdown from a few seconds to zero is actually quite easy. It's the" countdownSeconds" variable in src/components/dialogs/ResetHeaterFaultDialog.vue

@Phaedrux I actually did it by adding the lines 205 to 207 here :

We're working on DWC3.4.5 but we can also have it work on 3.5

@dc42 Thanks! It works perfectly now

@Herve_Smith If you compile your own DWC, changing the countdown from a few seconds to zero is actually quite easy. It's the" countdownSeconds" variable in src/components/dialogs/ResetHeaterFaultDialog.vue

@Phaedrux I actually did it by adding the lines 205 to 207 here :

We're working on DWC3.4.5 but we can also have it work on 3.5

Sorry I forgot to mention that this code section is normally in ToolPanel.vue line 491

Hi,

I'm trying to have DWC display a message instead of 2000°C ("n/a" in this example), here is the fix I tried to implement but nothing seems to work, it keeps displaying 2000°C when the sensor is disconnected.
Does anybody have an idea of what I'm doing wrong here?

My fix is are the commented lines 184 to 186 :

Thanks in advance,

Hugues

I strongly advise to not put any M98 inside daemon.g as it can disrupt the main DDARRing and cause stutter in the movement. What I usually do is copy the macro inside the daemon.g and even then some commands might disrupt the movement, at least not the whole macro will cause problems. Maybe we can queue the commands in a different G-Code queue with RRF3.5 to avoid all of this.

@chrishamm I isolated the problem to be specific to only one of our machines. So it's not firmware related, the problem is on our end

@chrishamm Weird, maybe I need to update DWC as well? All my duet3D-firmware modules are updated I don't see why it wouldn't work. I'm trying to find what broke during my merge with 3.5-dev.

I'm struggling to install avahi correctly so I'll try to find something else to test the mDNS.

Hi,

I saw the mdns fix at this commit and copied it into my current RRF3.4.5 branch and it works!
Now with RRF3.5b4 where it's already implemented, when I upgraded my MB6HC to it, saldy my mac doesn't get it with the mDNS even tho it worked on RRF3.4.5 with the fix.

An I missing something? Does anybody have the same issue? Did something else changed regarding networking in RRF3.5?

Thanks in advance,
Hugues

@JRCL I don't think it would be a great idea to anneal inside the machine itself since that would mean temperatures beyond 150°C, I'm not familiar with these materials though. If you have a chamber that can go high enough with a good temperature uniformity, printing a non-modified PEEK can be an idea but it is a nightmare to print anyways. For high temperature applications with FDM I tend to recommend Ultem 1010 or 9085. PEEK is better but it's more aimed towards high chemical resistance, mechanically it won't be better if it's not printed correctly.

@JRCL Funmat and Creatbot probably use a modified PEEK that needs annealing. In any case, the best practice is to focus on chamber temperature uniformity before going after high temps.