Thanks. I've used that file to verify that the fix works. And it's not your problem, it mine; because one of my principles is that software should behave reasonably whatever input you throw at it. If everyone took this attitude, there would be far fewer security vulnerabilities in released software.

@peirof You have changed two things in your example diagram image:

The Plus / Minus ordering of the icons in

Removed an arrow from the icons.

Regarding (1), any order is fine with me.

Regarding (2), I feel very strongly that we must keep both arrows on each icon. The "squeeze together" arrows vs. the "spread apart" arrows are intuitive for printers that move either the nozzle or the bed. Any single arrow is incredibly confusing for a subset of operators.

Thank you all for your answers! 🙂
I did consider using a macro for that but for me it seems a little bit excessive that one needs to create a macro in order to display the correct object height... I don't like having too many files in the /sys folder because it clutters up the view which gets very annoying on a small tablet that I use to control the printer (and since it's a DIY printer I do need to access the config and toolchange macros quite often).
But anyways, if adding one letter to the end-gcode fixes the problem then I'm happy 😄 Will try that tomorrow!

You can handle power failures gracefully. There's a resurrect function you can configure by filling in the resurrect-prologue.g file.

That sounds like the right solution. I will try it out when back at my printer. Is there a comprehensive list of all supported system .g files somewhere?

Would that then also solve the issue of homing Z doing the same thing? I would guess so, the only thing I am wondering is whether this works when using the endstop as the probe.

@DeltaCon, it's not confined to the 0.6 version, but the build for the 0.6 version has fewer buffers so if buffers are being lost then they will run out faster.

Let me know if you manage to find a way to reproduce it. It's probably related to network activity (multiple network clients? clients disconnecting?), or USB activity, or turning debugging on (M111).

@dc42 said in stepper motors out of sync only in webcontrol:

M203

So I check the Config File and the value read:

M203 X15000 Y15000 Z15000 ; Set max speed, 15000mm/min

This is was off by about a factor of 10 in all axis, must have been a mistake by the operator who did the original setup, still shocked the com execution never in countered this problem.

Thank you for pointing me to the problem!

This is with a single extruder

We could add "current F parameter" to the object model. Then, when the OM is fully implemented in RRF3, Duet 2 users will be able to retrieve it using M408 P1.

valid bug, checked at my side on Chrome, the same bug

@jcoelho said in Duet HTTP requests documentation:

Really happy that you were able to do that as a web developer beginner! Thanks for the url, it really details the body as I wanted. The issue with using the network monitor to view the request/responses is that you only observe some options and not all of them. Sure it's a way to get some information but you can actually be missing a lot of it.
Are you interested in working on something together? I'm beginning a living on software engineer but would love to create something with others and share it. If you want to join me, let me know.

That would be great as long as you can tolerate a beginner! Not sure how much use I would be. I am on github, same username.

I'll catch one next time the heater faults.

@Christoph13524 Safari keeps giving problems - if you can use Chrome please do.

Thanks.

Waiting for a RC of v3 and a v3 board before I take the plunge.

Frederick

Thanks for the report, I'll fix it in DSF 1.1.0.6.