@Simon-4 As you are not using firmware retraction, then the retraction parameters will be whatever you set them to in the slicer. The firmware doesn't "know" anything about the speed and distance values on the data sheet, unless you configure them using M207.
For info, the published retraction distance of 1.25 mm will vary depending on things like nozzle diameter, filament type, temperature and few other factors.

Edit. I should probably add that the maximum speed, acceleration and jerk values that you define elsewhere in config.g (using M203, M201 and M566) will be respected regardless of whether you use slicer retraction or firmware retraction. However, these are maximum allowable values which largely depend on what the motor/machine/mechanics are capable of and therefore should only be used to cap the maximum allowable values, and not be used as a means of controlling retraction settings.

@droftarts I see, so it's not the thermistor as I measured it and it's 100K.
I guess I will check where the wires were damaged and fix the open circuit since I touched both ends of the wires together and nothing changes.

Thank alot!

@SanderLPFRG You could try keeping the G91 + G1 Z1 in your tree, but then in tpost you could set up a restore point move?

https://docs.duet3d.com/User_manual/Reference/Gcodes#g1-controlled-linear-move

Example - G1 R2 Zxxx , with xxx being your Z-hop height, and then follow that with G1 R2 Z0. Likely would want both lines at the end of your tpost. This would restore the print head to the position stored before the tool change, but offset by Zxxx. Then it would restore down to an offset of Z0 from the restore point (thus completing the Z-hop).

@droftarts I found that I needed to change the pwm frequency, then it started working. thank you.

@mikeabuilder According to https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_tuning#running-auto-tuning

When tuning, auto tuning will perform a number of phases (heating, settling, fan off, fan on), cycling between the target temperature and 5C below it. It measures the heating and cooling rates on the last 3C each cycle, and accumulates the mean and standard deviation. Typically it will cycle heating/cooling 8 times, but can be as many as 30, if the readings are not consistent (noisy thermistor, or a large thermal mass). You can use the Y parameter to alter the hysteresis.

It's worth looking at the temperature graph as tuning is happening. If the tuning cycles are 'inconsistent', it can point to a number of problems, beyond 'noisy thermistor, or a large thermal mass':

A tuning cycle that speeds up could indicate inadequate cooling of the hot end cold side Poor thermistor contact can give variable readings thermistor very close to heater, so the local area heats up, but the rest of the hot end is still cold (common with silicone heaters with the thermistor embedded) draught on heater from cold side cooling inconsistent heater heating (poor wiring, failing heater) poor thermistor wiring, or interference, would generally show up as spiky readings.

There's probably plenty of other causes of inconsistency that one could imagine. I'm pretty sure this isn't a firmware issue!

Ian

@DonStauffer I'd suggest that you move the BLTouch reset to be after you have lowered the bed (that way if part of the reset involves any sort of probe deployment it should be safe). I'd also suggest that you lower the motor current when performing the probe, just in case something goes wrong with the probe.

@PHavey Did you ever get a good PID tuning for the 100W heater? I'm in the same boat now, although the tuning doesn't exactly fail. I get "Warning: heater behaviour was not consistent during tuning". I don't know how much of a problem that is, but nothing has made it go away when I autotune.

@dc42 I can work around it. It just took me a while to figure out what was happening. I ended up with 2 tools heating at the same time unexpectedly.

@droftarts I've dismantled the filament monitor and it looked fine. I think I may have found the issue, I have about 20cm length of ptfe tubing to route the filament from the side of the frame in to the top of the monitor which sits on top of the bondtech bmg extruder which sits directly on top of an e3d v6 hotend. The tubing is a very shallow 15cm or so radius curve and it feels like there is very little if any resistance. I printed a couple more test prints with the tubing removed and just unrolling and feeding it manually and the prints competed successfully.
This is strange as I have other printers using more ptfe tubing to route the filament with no issues. I played with the tension on the extruder and it seemed to make no difference.
Hopefully this was not just an anomoly, I'll make up a new filament holder above the extruder which should fix the issue.

@tas I just assumed that Z was 1 because of gravity. I think that the frequency domain analysis of each axis is done independently since Z shows a very small amplitude in all of my original graphs.

@gloomyandy thank you, I did eventually figure that out. I did check the wiki and firmware, and the accelerometer is already collecting data at the max frequency (1600 hz). And the biggest issue that was occuring with the long tail of data is the hot end cooling fan frequency was creating a false signal.

Regarding my specific case, I was able to solve a lot of my issues by securing the cable to the gantry because the rubbing on the frame was causing lots of noise. And the low amplitude seems to just be from my printer being particularly rigid at the speeds I can go (score 1 for past me!). I'm currently limited by hot end flow rate, so maybe if I switch back to my volcano, this will become more important.

@droftarts Thank you so much Ian. Really appreciate that detailed input!

You are correct about the crash, occasionally it can get so bad that even with increasing M671 S parameter, it'll crash.

I wasn't sure about including the M906 and M350 commands, I only included because the gcode dictionary says

M584 must come earlier in config.g than any M350 and M906 commands.

But it makes sense they're not needed as already declared originally in order.

Thanks again Ian!

@droftarts OK, it's not a bug, it's a feature! 🙂

@gloomyandy ok. thx

@Thalios

That's the answer i was looking for!

Glad I could help. Apropos your ”dumb question”: obviously, my prose was just waiting for the perfect question to be asked 🧐

@DonStauffer I think you should post your config.g bed.g and homez.g files

You might also want to try running some tests to see how repeatable the results are from your z probe. That test can also be used to help you decide what acceleration and dive speed.

The purpose of that final probe is to reset your Z=0 (though I'm not sure what that G30 X150 Y150 Z-99999 will actually be doing, I suspect it may just be storing the value in p0, but I may be wrong). The normal way to do this would either be to run G28 Z or to position the probe and run just a plain G30. You need to do this because the adjustments made to level the bed will mean that Z=0 is no longer valid.

@Simon-4 If the fan you want to monitor is fan 1, and your tool is using heater 1 the basics would be something like this:

; pause if fan is slow if state.status = "processing" & heat.heaters[1].current > 50 & fans[1].rpm <= 1000 M118 S"fan problem" M25

Loops are indicated by the indentation, so make sure you copy the indentation - you need the equal spaces at the start of the lines after the 'if'.

This checks to see if the printer is currently printing, and heater 1 is currently at more than 50 and fan 1 is at less than 1000 rpm, if all that is true, it displays a message and does M25 to pause the print. You will need to remedy the problem before resuming the print manually.

You should create a file in sys folder, it doesn't matter what it is called, put that text in it and save it. Then rename the file to 'daemon.g'. The file will run every ten seconds, and check the fan speed.

If you want to edit the file rename it to something else (I normally just make it daemon.g.x), edit the file and then rename it back. If you just edit it when the machine is trying to run it every 10 seconds things can go wrong.

@droftarts Thank you soo much!
Bed heater is 60w and slow auto tune say
M307 H0 R0.150 K0.155:0.000 D15.28 E1.35 S1.00 B0
If I change to B1 will it heat faster?

@oliof Thanks, all seems to work as it and apparently been that way for a long time, just was curious why. I am almost complete, just have to get the macros copied over, set the bltouch up, run a grid and test a print job. Thanks again!

@zBeeble If you're needing to figure something out either way, and just wanting to handle printer pausing during print, probably best to use the active and standby approach suggested using M568, but if you were already using variables or have another use case this is an alternative.

See https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#variables

RRF has variables you can write to and then refer to in gcode by putting the name inside {these}. It also has local variables that stay inside one gcode file, useful for loops and things.

You could have in config.g something to create an empty variable:

if !exists(global.nozt) global nozt = -1

Which creates a global if it doesn't already exist.

Then in your pause.g have something like

set global.nozt = heat.heaters[1].active

before you switch off the tool heater (or switch it to standby) (this assuming your nozzle in the tool is heater 1). Then any subsequent code can know what the temperature had been (by referring to global.nozt) e.g. with G10 P0 S{global.nozt} to switch back on with taht setpoint.

The advantage this has is if you are doing other things with the temperature besides just standby and resume. I have some physical buttons on my printer which heat and feed filament (mainly when doing a manual colour change and flushing some through), so I want the printer to know the extrusion temperature of the filament currently loaded easily, so I write that into a global variable and use it both when resuming after pausing and when heating the tool (potentially from fully cold) to feed some filament.

@infiniteloop
Ok, problem appears to be solved.
All carriages removed, cleaned and reinstated. Belt tensions checked and stepper motor current reduced by 80%.
Added always on 40x40 cooling fan to underside of board.
Thanks for all the comments!