@dc42 Done. ##986

@dc42 Issue is created: https://github.com/Duet3D/RepRapFirmware/issues/979

One offtopic question, if I may: from your standpoint, is there anything I might add/contribute to clarify or increase understandability of https://github.com/Duet3D/RepRapFirmware/issues/915? I just want to make sure that the feature request contains everything that might be of help in case it might be chosen for implementation some time in the future.

When I had created that one, I had several other issues to fight with, therefore I admit I do not consider that data I presented there to be really optimal.

Braintoe created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: allow more than one keep-out zone #979 Braintoe created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add "suppress message" G30 probe option #915

Update: in case someone might need it, this request is partially solved thanks to the new M308 U and V parameters - at least if the required switching speed between the areas can be slow enough to be handled by daemon.g.

@chrishamm Thanks!

@dc42 Submitted #975, thanks.

@LindsayC Just an update on what I've ended up doing. As we wanted to use the ethernet connection as our main comms, we've implemented the DuetHTTPclient and telnet connection together.

The DuetHTTPclient has the full object model updating in the background that can be queried regularly with less time-critical stuff like reporting in the UI things like temperatures of chambers etc.

The telnet allows more time-critical comms without the overhead of the DuetHTTPClient like needing to wait for update of the object model.

Single cable solution with a lot of flexibility.

@CCS86 I think the main focus right now is getting 3.5 out the door.

@ErlerPrint3D my recommendation is to use the Duet3D magnetic encoder instead of quadrature encoders. That way you can calibrate each motor individually, before fitting the belts that couple them together; and you won't need to execute a tuning move each time you power up. The magnetic encoder also has much higher resolution that quadrature encoders.

@T3P3Tony That would be my guess, but it would really be a guess, I've not looked that closely at it.

@T3P3Tony I think it would be logical to add a fault state possibility to all the different subsystems, eg. tools, axes and to machine (or system) level, similar to heaters.

For example, if a tool change macro fails, that could trigger a fault state on the tool, raise a "toolchange-fault" event, and also change the current machine state to paused.
I think it would make sense to pass a "cause" to a pause (or any automatically called) macro and let the user decide what to execute depending on what caused the pause, eg. user-request, toolchange-fault, heater-fault, etc...

I think handling aborts in system-level macros could put the whole machine into a fault-state which in turn could further prevent running any other "doing" action, eg. tool change, move, home, etc. which would change any current (physical?) state.

There is something here that has to be thought out: allow executing "disable" commands in system-wide fault state, eg. turn off heater, spindle, motor, power, etc. So it is not that easy to just prevent any executive command to run.

I think resetting any fault could be done in a standardized way, just like how resetting a heater-fault works already with M562. Maybe it could be extended to be able to reset any sort of fault (selectively). Then the user could decide whether it wants an UI popup, or it recovers automatically from an event macro, or issues the command by hand, etc...

Just my thoughts...

@NineMile its already a feature request https://github.com/Duet3D/RepRapFirmware/issues/761

T3P3 created this issue in Duet3D/RepRapFirmware open Report filename in error messages #761

@ErlerPrint3D yes this is implemented in the forthcoming RRF 3.5.

@Dakota Bambu uses piezo under bed sensors.

@T3P3Tony PS, though: this blog series is awesome! I hope those involved can pick it back up sooner than later. What a cliffhanger!

@droftarts As I saw my name mentioned - there is a typo in the above although the meaning should be obvious. "What I do on my X axis..." should read "....on my Z axis". I'll correct my original post.

@DocTrucker That's what I meant with jerky motion. You can use bigger steps than 5 microseconds for more speed, but too much and they get jerky.

@dc42 is it implemented or in the roadmap?

@DavidG_68kg_PLA said in Marlin M86 counterpart: reduced idle temp:

while the Machine is in sequential pause midprint

What you you mean by "in a sequential pause"?

Pausing in RRF executes the pause.g macro (or for some types of pause an alternative macro if present, such as filament-change.g). It's common to set the hot end heater to standby in pause.g and then to set it back to active in resume.g.

@curieos said in Save/Recall Heater State:

I'm not sure, I had some concern about changing values that aren't necessary to be changed. It feels like bad practice, but I can't think of a real problem it would cause.

It will not cause any problems if my experience, using firmware 3.4.6, is any indication and I use variables extensively, both local and global. Currently on my 4 tool printer I have 70 some global variables and many things get updated in a group regardless of how many values within that group may actually have changed. No problems to date.

Frederick