Posts made by Hugsy

@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.

@JRCL Just my two cents but for PEEK you should aim between 150°C to 200°C in the chamber.
If you don't want to go watercooling maybe compressed air should do the job?

@dc42 That's also what I expected but looking at the logs I don't see any warning.
Thank you for the insights on the warnings.

@dc42 We were running either a custom 3.2 or 3.3 at the time, now we are on a custom 3.4.5 and have 0 issues apart from the missing driver overtemp warning.

@dc42 On some boards I observed that some commands were misinterpreted, when we sent an extrusion command we sometimes saw a retraction. On some rare occasions the F speed was completely wrong and the extrusions were too fast (scary fast actually).
This was extremely random though so we added some cooling just to be sure.
This is on 3HC v1.01

Hi,

Just a feedback on my experience with a few 3HCs running on a 6HC. Currently, they're running in a heated chamber with a weak cooling solution, got a MCU temperature readout of 107,8°C yesterday and just above 100°C today.
Funny thing is at some point they started to giving out driver "over temperature shutdown" without any "over temperature warning" so they might be in warning mode all the time, I just don't know.

But geez, these things can cook! ^^

@aze You should try to run the movement commands on a separate G-Code command queue within the daemon.g file. Should only work in RRF3.5

@dc42 Actually I did, I have one prototype with 200 and 400 step motors mixed together, no problem at all. Works on RRF3.4.0

@chrishamm Hi Chris,

It was at RRF3.3, if I recall correctly it was the syntax on some commands that changed the motors current, it was a long time ago and I think these commands were changed (in our macros) so it's not relevant anymore. Actually I found the issue by looking into it, we rely on a lot of global variables in the machine and their support started at RRF3.4 on SBC mode, so it's not a problem anymore.

@T3P3Tony Okay, we can work with a 1 tab per client. Although we observed that 2 different IP clients can consume each other replies already, and while I did tests with one client that has multiple tabs, multiple clients with one tab each lead to the same problems. Do you want a multi-Wireshark session with different clients ?

@T3P3Tony Oh wait, that's interesting. We're not hitting the 8 http sessions limit (I did quite some tests with that setting in the firmware), but you're telling me a physical client can have as many tabs as he wants and it will only generate 1 http session ?
Is it a hardware limitation of the ethernet chip or SoC on the 6HC to be limited on the number of sessions ?