@Rodrigue-Richalland only thing would be roll your own layout using BtnCmd https://plugins.duet3d.com/plugins/BtnCmd.html

@chrishamm Hi thanks you for your answer. Ok I see now. I don't understand why this menu been moved on mobile version, It's not possible to control all the axis, the hotend and the bed on the same page.

@Masterjuggler I don't think removing those extra headers has any effect - they're ignored by RRF anyway. As previously said, a Wireshark dump taken between Duet and middleware may help us further figure out what and how many headers need to be handled in your config scenario.

@Rob65 I created issue https://github.com/Duet3D/DuetWebControl/issues/475.

dc42 created this issue in Duet3D/DuetWebControl closed [FeatureRequest]: When selecting the filament to use from the Tools section of the DWC, sort the filaments by name. #475

@chrishamm

Ok, I think I figured it out. Yesterday before all this started, I was trying to figure out how to manage my config files (working to set up a tool changer and wanted a real system with git to manage the files). I was exploring how to essentially rsynch the files from my mac to the duet.

As part of this I enabled FTP.

I then started doing some test scripts to synch the files, including copying back and forth a bunch of tiles.

I then did a 'clean' install of 3.4.5, but of course it had an empty /sys directory and was complaining, so I copied back in my config. That config had a line enabling ftp. So, not quite the "clean install" I thought I had.

With ftp disabled, I don't see issues. I do sometimes see a single "connection lost retrying" cycle before the full page comes up, but it appears to be able to recover from it. Normally I don't see any retry, just a clean load.

Summary:
If you are having issues with Duet Web Control having difficulty connecting on a Duet 2 Ethernet (or likely Duet 2 Wifi), make sure you have ftp disabled. For some reason, the resources allocated to ftp (even if they aren't currently in use) make the web server much less resilient to any network noise.

Thanks Phaedrux, I had tried all of that with no luck.

o_lampe wins the prize, my end-of-print macro contained

M141 H2 S0 M141 H3 S0

When it needed to contain

M141 H2 S0 M141 P1 H3 S0

Sending "M141 H3 S0" immediately--and unsurprisingly--replicates the problem, so, there we go.

Thank you both very much! My printer otherwise seemed to be in perfect working order, so this was really bugging me more than it needed to.

@jay_s_uk Ok. Thanks for your help its much appreciated.

@droftarts @Phaedrux

I've finally found the cause of the issue.

When I installed my new router, around the same time my Iphone did an update.

So I had a look around on my Iphone, Settings, Security, Safari, and found that some settings weren't as they were or how I thought they should have been.

So I started tinkering around with some of these settings. Under Privacy and Security I found that "Prevent Cross-site Tracking", and "Block all Cookies", where both enabled.

With disabling these 2 settings, Wham bam thank you ma'am, Iphone is presenting the full ios DWC and it now appears in my routers client list.

How the heck was my iphone stopping the duet appearing on the router?

Surely having these 2 settings enabled on my iphone is just for the iphones security, not my router or network?

Anyway, it's now working and hope this may help others.

Thank you for your help.

@chrishamm Thank you for the suggestion. I used a spare SD card with a fresh full bullseye image, then installed the DSF software as per the link and unfortunately, I ended up back where I started with the dropdowns still not working. I guess it’s the same issues with working with the Bullseye OS. as everything was working perfectly with the Buster install. It’s not a big problem as the machine is still working great. It is only when I want to change materials, I then have to set the temperature remotely (I’m not a great fan of the onscreen keyboard) and ultimately as a work around I can easily create a couple macros to heat up and cooldown until Bullseye is fully compatible.

@chrishamm Okay, that is confusing.
Why do we have two objects in place which provide the same information, but maybe they don't in reality?
Currently, I use the heaters to get the heating values for all tools and the bed and besides the described behavior this complies also with the UI values.
But in the end, reflect heat.heaters[1] the heater of the tool#1.

Will check the tools object later and report if the behavior is the same.

[ { "active": [ 0 ], "axes": [ [ 0 ], [ 1 ] ], "extruders": [ 0 ], "fans": [ 0 ], "feedForward": [ 0 ], "filamentExtruder": 0, "heaters": [ 1 ], "isRetracted": false, "mix": [ 1 ], "name": "Hemera", "number": 0, "offsets": [ 0, 5, 0 ], "offsetsProbed": 7, "retraction": { "extraRestart": 0, "length": 2, "speed": 16.7, "unretractSpeed": 16.7, "zHop": 0 }, "spindle": -1, "spindleRpm": 0, "standby": [ 0 ], "state": "active" } ]

Looking at the response, I (as expected) only get the reference to the heater number and not the heater values. So the values from heat.heater[1] do not fit the GCode call, but the gcode also do not show the temperature values, right?
M409 K"heat" show the same IMHO wrong active and standby values.

M409 K"heat" { "key": "heat", "flags": "", "result": { "bedHeaters": [ 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ], "chamberHeaters": [ -1, -1, -1, -1 ], "coldExtrudeTemperature": 160, "coldRetractTemperature": 90, "heaters": [ { "active": 0, "avgPwm": 0, "current": 22.47, "max": 120, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 1.112, "deadTime": 2.3, "enabled": true, "fanCoolingRate": 0, "heatingRate": 0.402, "inverted": false, "maxPwm": 1, "pid": { "d": 1.219, "i": 0.0749, "overridden": false, "p": 0.74414, "used": true }, "standardVoltage": 0 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 120 }, { "condition": "disabled" }, { "condition": "disabled" } ], "sensor": 0, "standby": 0, "state": "off" }, { "active": 220, "avgPwm": 0, "current": 29.2, "max": 300, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 0.693, "deadTime": 2.2, "enabled": true, "fanCoolingRate": 0.784, "heatingRate": 4.248, "inverted": false, "maxPwm": 1, "pid": { "d": 0.115, "i": 0.0115, "overridden": false, "p": 0.07456, "used": true }, "standardVoltage": 24 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 300 }, { "condition": "disabled" }, { "condition": "disabled" } ], "sensor": 1, "standby": 220, "state": "off" } ] } }

a5f32d19-36cb-49d1-ae16-1ea60aaa949e-image.png

Of course, I am rather new to the Duet and RRF API so please feel free to correct me if I am wrong! I just want to make sure that both the API is delivering correct and consistent values and that my integration is working fine 🙂

@oliof

if in doubt, talk to the copy rght holder (i.e., Duet3D). They may be open to dual license DWC under the right circumstances.

that's right, I will consult to copy right holder

Please let me know that you would like to release it as OSS as much as possible.
I just had a hard time handling it when it contained confidential company information 🙏

@deckingman figured it out. you were correct. I bought a brand new E3D RapidChange Revo Voron Hotend. Its broke before even using it. swapped out for the phateus dragon setup i had and it all works now.

Thank you everyone,

I will look into all of that info.

Cheers,
Gumby

@tecno You have quite different M307 commands in your config.g compared to your config-override.g.
config.g

M307 H0 R0.647 K0.182:0.000 D2.23 E1.35 S1.00 B0 M307 H1 R2.943 K0.349:0.411 D6.80 E1.35 S1.00 B0 V24.6

config-override.g

M307 H0 R0.654 K0.274:0.000 D1.90 E1.35 S1.00 B1 M307 H1 R1.916 K0.577:0.000 D10.84 E1.35 S1.00 B0 V24.6

I expect the ones in config.g trigger the first two warnings, then only H0 is triggered by the M307 in config-override.g. If you're using config-override.g, you can remove the M307 commands from config.g (they are being overwritten by config-override.g anyway), and then you should at least get less warnings.

Ian

@Peter-Lebiedzinski I've back-ported the fix to the 3.4-dev branch, so it will be included in the forthcoming 3.4.6 release.

@dc42 @Notepad Setting the CORS site parameter on the Duet web server has no effect for other domains, only for those that want to access web resources from the Duet itself. You probably need to turn off CORS (CORB) on the IP webcam if it supports that. The other solution may be to disable CORS altogether in your browser, but I wouldn't recommend that as it can be a security risk.

I was able to create another issue with simpler g-code. When cancelling the print during the while loop, selecting the file for printing again will resume from the cancel location instead of starting from the beginning. I let the print finish executing the rest of the loop and then attempted to print again, but was met with the error: variable 'parts' already exists. It is impossible to start the print from this point without an E-stop or an M999 command.

echo "Begin" var parts = 0 while var.parts < 5 G1 X0 Y0 Z20 F3000 G1 X30 G1 Y30 G1 X0 G1 Y0 G10 P2 L20 X-50 Y0 Z20 set var.parts = var.parts + 1 echo "end" M0

MicrosoftTeams-image (16).png

To help trace it down you can add M117 message commands between the lines in your homeall and slicer start gcode to see where it's getting thrown. That may help narrow it down.

@techworld Glad you got it working.

The answer is "yes" you can auto-pause on layer change (using - pause yes and -detect layer). I encourage you to read the documentation as there are additional things to consider (see -rest and also the use of -seconds with -detect). Note that depending on your printer the resultant model may not be "great" - cooling between layers etc.

Lets close this discussion (about DuetLapse3) in this thread and continue future ones in the DuetLapse specific thread.

Do you have a link to "the famous one with Octoprint"? I'm curious 🙂

@Nordle the accelerometer plugin was the plugin that came before the input shaping plugin. In the 3.5 betas, the accelerometer plugin has been removed and the input shaper plugin is now built in