@oliof Awesome thanks for that!

I came up with the following solution:

content of driver-warning.g

; driver-warning.g ; driver warning - 51.0 : 1024 ,Driver 51.0 warning: position tolerance exceeded if param.B > 0 && param.D == 0 && param.P == 1024 && move.axes[0].homed == false && move.axes[1].homed == false M99 ; ignore warning when drives are not homed echo "driver warning - "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S} if state.status == "paused" || state.status == "pausing" || state.status == "resuming" M99 ; ignore this event - it is already handled if !exists(global.event_driver_stall) global event_driver_stall = true ; check if a printjob is running ; if it is a can connected driver in closed loop mode with error position tolerance exceeded (param.B > 0 && param.D == 0 && param.P == 1024) if job.file.fileName != null if param.B > 0 && param.D == 0 && param.P == 1024 set global.event_driver_stall = true M25 ; pause print and rehome X and Y M207 Z{tools[0].retraction.zHop+0.2} ; raise z-hop 0.2mm to prevent further crashes set global.resume_deferred = state.upTime + 5 ; resume print after 5 seconds else set global.event_driver_stall = false ; do not rehome while pausing G91 ; relative positioning G1 H2 Z0.5 F600 ; lift Z relative to current position M568 P0 R0 S0 A0 ; disable hotend M25 ; pause print

content of driver-error.g

; driver-error.g ; called to home x and y after stall detection ; driver error - 51.0 : 3072 ,Driver 51.0 error: failed to maintain position if param.B > 0 && param.D == 0 && param.P == 3072 && move.axes[0].homed == false && move.axes[1].homed == false M99 ; ignore warning when drives are not homed echo "driver error - "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S} if !exists(global.event_driver_stall) global event_driver_stall = true if state.status == "paused" || state.status == "pausing" || state.status == "resuming" set global.resume_deferred = 0 ; reset resume_deferred M99 ; ignore this event - it is already handled ; check if a printjob is running ; if it is a can connected driver in closed loop mode with failed to maintain position (param.B > 0 && param.D == 0 && param.P == 3072) if job.file.fileName != null if param.B > 0 && param.D == 0 && param.P == 3072 set global.event_driver_stall = true M207 Z{tools[0].retraction.zHop+0.2} ; raise z-hop 0.2mm to prevent further crashes else set global.event_driver_stall = false ; do not rehome while pausing G91 ; relative positioning G1 H2 Z0.5 F600 ; lift Z relative to current position M568 P0 R0 S0 A0 ; disable hotend M25 ; pause print

content of daemon.g

if exists(global.resume_deferred) && global.resume_deferred > 0 && global.resume_deferred < state.upTime if state.status == "paused" set global.resume_deferred = 0 M24 ; resume print

The magic is done by the global.resume_deferred. It is set to state.upTime + 5 which means 5 second delay.
The flow looks like the following

driver-warning event -> check if it is already paused if so, exit else set resume_deferred driver-error event -> check if it is already paused, if so, reset resume_deferred to 0 to disable it and exit daemon.g -> Check whether the delay for resume_deferred has already passed, if so resume the print.

@infiniteloop I have not tried this material of course, but I have indeed trying to shorten queu lenght in the past several times wheing trying make a macro introduce code faster in the queu for example. I can perfectly agree and confirm that printing becomes "bumpy". So, in the case of this talking about this material, if the movement suffers this kind of artifacts, for sure we can predict flow will be completly out of control because we can maka a paralel situation when you have moisture on you filement: can can get away sometiomes with lot of moisture, but at the moment the nozzle stops just for hal a second, you will see material being extruded A LOT.
From an engineering point fo view, when you face a develpment where at the very beginning the posible solution already faces a lot of problems... that is my sign to "ok, this solution will not end up well, lets look for another aprouch" and this is the case.
In this case, if you already recognize that the material has not a predictable flow, trying to control that chaos is something that will not get to a good solution. I would go towards try to get a better material, OR just not try to get a eprfect flow control.
Remeber this: this has already happened in the past. Maaaaany years ago, in the time where filament diameters where not as precise as today, opeple tried to use optical filament diameter sensor in order to measure diameter on the fly and adjust the flo on the fly. And that aprouch NEVER worked because you had to provide the firmware with the exact offset between the sensor position and the tip of the nozzle, and just an error of 0.2mm gives you more error on the flow calculation than a +-0.1 in fialment diameter so...
I still have one of those sensors by the way lol

@droftarts Dropping R down to 480 allows me (so far) reliable initial heating, with only about 0.8C overshoot on the initial run to 70C. That is fully acceptable for me.

So, thank you for pointing me into the proper direction. 🙂

@droftarts, @Phaedrux, @engikeneer, thank you all for your replies. Turned out to be a faulty heater cartridge. I received a new heater cartridge from an official E3D reseller. It has the correct resistance and is working well.
I suspect the original 30w heater was faulty from the start. When I first got my V6 3 years ago, I think I was only ever able to tune to around 260 and now that I'm printing close to that, it wasn't stable while also pushing filament through.
Also, there is adequate space between the heatsink and heater block.
Glad to have my printer back. Thanks for the help!

@JJJJ said in Printer pausing at start of each layer.:

@droftarts Yeah its strange, still got to tweak the settings as im getting a very large seam still, but its not pausing now.

I'm guessing your cura has retract at layer change turned off.

@mdalacu For the Meta Gcode programming language, see https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands
For a list of the Object Model variables, see https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation
There are OM entries for:
state.currentTool - Number of the currently selected tool or -1 if none is selected
state.nextTool - Number of the next tool to be selected
state.previousTool - Number of the previous tool

And quite a few in the tools[] section that might be useful https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#tools

Ian

@droftarts ok
Thanks

@droftarts Thank you for your reply, that's very helpful I will try changing the speed then.

This is the printer they have at work and when I joined a few other people had already tried to get it working with no luck. When I went to update it I forgot to save the original config, it was on version 1. something. But it wasn't really working then anyway, so my plan was to start again so I did the config from scratch.

I have also struggled to find any information about the printer, so that explains why then.

I've managed to get some prints from it now I rewired the hot end and added a new extruder but it's just the first layer and z offset causing issues now.

I will try the things you have said, thanks again for your help.

@Darby-Cox this is a common issue when using external drivers. Such drivers have a limit to the speed at which they accept pulses. You have the M569 T parameters set at 2.5 microseconds high time and 2.5 microseconds low time, so the maximum pulse rate is 200kHz. You also have a high steps/mm of 320. So the maximum rate at which the belt can move is 200000/320 which is 625 mm/sec. On a CoreXY machine this will be the maximum diagonal speed. The maximum speeds of X and Y moves will be double this.

To get higher speeds you will either need to reduce the M569 T parameters if your servo drives can handle a higher pulse rate, or reduce the steps/mm by reducing the configured steps/rev of your servo drives or by using larger radius motor pulleys.

@Notepad said in uniform wave artifact on all prints:

WS16

ok so i loosened lead screws and waves got even woth so i think i need to work in makeing sure build plate is stable... 😞 before is did 3Z itwas perrry well i guess let me play with mechanincs and try that adapter too

tnx for leading me to right direction

@BartW22 Hmm I've had a quick look, but unfortunately it looks like it was not using a fixed sample rate, that makes it a little tricky to process the results with the online tools I could find. But even if you can work out the frequency I really doubt if the RRF input shaper is going to be able to handle that level of oscilation it is a bit more than your typical 3d printer ringing! But what do I know, maybe it can help.

@chrishamm That works, thanks!