Anyone in the UK then I can replace drivers and fets, I already replace 80pin Atmels in telescope mounts so these would be no problem for me

i did this with limited success for a servo on out7 with ballvalve,

i created a macro called airservovalve with the below

; AirValveServo
if fans[0].actualValue = 0
M280 P1 S0 ; Close the valve
elif fans[0].actualValue >= 0.01 && fans[0].actualValue <= 0.10
M280 P1 S18 ; Open valve 10%
elif fans[0].actualValue >= 0.11 && fans[0].actualValue <= 0.20
M280 P1 S36 ; Open valve 20%
elif fans[0].actualValue >= 0.21 && fans[0].actualValue <= 0.30
M280 P1 S54 ; Open valve 30%
elif fans[0].actualValue >= 0.31 && fans[0].actualValue <= 0.40
M280 P1 S72 ; Open valve 40%
elif fans[0].actualValue >= 0.41 && fans[0].actualValue <= 0.50
M280 P1 S90 ; Open valve 50%
elif fans[0].actualValue >= 0.51 && fans[0].actualValue <= 0.60
M280 P1 S108 ; Open valve 60%
elif fans[0].actualValue >= 0.61 && fans[0].actualValue <= 0.70
M280 P1 S126 ; Open valve 70%
elif fans[0].actualValue >= 0.71 && fans[0].actualValue <= 0.80
M280 P1 S144 ; Open valve 80%
elif fans[0].actualValue >= 0.81 && fans[0].actualValue <= 0.90
M280 P1 S162 ; Open valve 90%
elif fans[0].actualValue >= 0.91 && fans[0].actualValue <= 1.0
M280 P1 S180 ; Open valve 100%

Then in Daemon.g added this
M98 P"0:/macros/Special Scripts/AirValveServo"

The only issue was it was a bit slow responding to fan speed changes

@dc42

Thankyou sooo much
I can confirm it is fixed on the 3HC
Multiprobing each point

and

finally getting consistent results with no gradual increase in height from front to back

This is much more like what I had before adding 2 more motors on X/Y and Z was on the mainboard

Ok, I got an answer that works for me

Im not a programmer but have been able to hack together a cura post processing plugin that seems to work fine for me.
I will attach it for anyone else should they experience the same issues.
Just drop it in the same folder as your cura post processing plugin scripts.
usual location
C:\Program Files\Ultimaker Cura 4.[xx.x] \plugins\PostProcessingPlugin\scripts

as a bonus it also makes my berdair more controllable, as it doesnt start turning until the S value is at least 26 and reaches max speed at 245'ish.
I can enter the berdairs start S value and Max S value and it now recalculates this as being the 0 - 100% fan range ansd also drops the decimal places by rounding

im also replacing any M107 with M106 S0

RRFFanScale.py

It is fixed in B7+2
see my post here

https://forum.duet3d.com/topic/25720/g30-stop-values-increasing-each-time/26?_=1641577026578

to confirm, Z is back on 3HC and multiprobing each point is giving good results again.

Thankyou @Phaedrux and @dc42

im running rrf 3.2.2 on my duet3,
if i start a print at 80mm/s (100%) from DWC, then go to the printer and increase to 200% via the paneldue (should now be 160mm/s.
I then press pause on the paneldue and then resume again, its like its now treating the 160mm/s as 100% but as the paneldue is still set at 200 it flys at around 320mm/s
ive tested this multiple times today and it does this every time.

any ideas if im doing something wrong or is it a bug ?

@marcossf said in levelling and mesh:

@MikeDC @Phaedrux Have a look at the David's answer in our thread about CAN delays with external boards:

@dc42 said:

I have put preliminary firmware that resolves this issue at https://www.dropbox.com/sh/cx760ysonlzzkjd/AACfsVfX4olHipuqmbWut5EKa?dl=0. Please test this firmware with care because I have only tested it using Duet 3 MB6HC + EXP3HC (the Z motor was connected to the EXP3HC).

If you are running your Duet with an attached Raspberry Pi then you must upgrade to RRF 3.4.0beta7 from the package server BEFORE you use these files.

Unfortunately we couldn't test it yet, so it's a good start point to see if this issue is addresed.

Best,

I will definately test these files next thankyou

@dc42 Thankyou

I will upload as soon as my current print is finished and put Z back on the 3hc.
Ill let you know here how i get on

@rjenkinsgb said in levelling and mesh:

@marcossf

One simple change that may help is just reduce the probing speed a lot, so any delays result in smaller errors.

In the config you posted earlier it is 300; try 50 or even less and see how that works?

I only use 60 even with a directly wired BLTouch!

As long as the clearance height is not excessive, it should not make all that much difference in speed but could increase accuracy a lot.

I have already tried this, It doesnt help the inconsistancy,
Thankyou for the suggestion tho

I have a berdair set up on my duet3, and have set the frequency to Q500.

for the printing I am currently doing i need minimal partcooling, mainly on bridges and support interfaces.

i have set 0% - 5% cooling in cura.

3 times during this print the berdair went crazy with 30% 60% and 100% fan

inspecting the gcode generated by cura i think i have found the issue.
2 of the lines pointed below.

I know rrf will take fan control parameter S as either 0.0 - 1.0 or 1 - 255
Cura is generating decimal places on all values above 0
it looks like RRF cannot distinguish values lower than 1 from values above 1 generated by cura so when it sees 0.3 and 0.6 it set my berdair to 30% and 60%

is there anyway to avoid this issue, any parameter to tell RRF which scale that we are using ?

@deckingman

well its a nice solution, ill be using it in other places too

Ok, I got an answer that works for me

Im not a programmer but have been able to hack together a cura post processing plugin that seems to work fine for me.
I will attach it for anyone else should they experience the same issues.
Just drop it in the same folder as your cura post processing plugin scripts.
usual location
C:\Program Files\Ultimaker Cura 4.[xx.x] \plugins\PostProcessingPlugin\scripts

as a bonus it also makes my berdair more controllable, as it doesnt start turning until the S value is at least 26 and reaches max speed at 245'ish.
I can enter the berdairs start S value and Max S value and it now recalculates this as being the 0 - 100% fan range ansd also drops the decimal places by rounding

im also replacing any M107 with M106 S0

RRFFanScale.py

@deckingman

I like this more and will try it thankyou

@phaedrux

yes i think it is, i will play with a couple more models with some small layer areas which will triger minimum layer times and the fan speeds a bit more

@Phaedrux

I tried your suggestion, but set it to 1.1 not 1.0 as that would be 100%

also under experimental i set the bridge fan to 5%

look what happened

im using very low percentage as the berdair does push a lot of air for each 1% increment

@phaedrux
the cura version im using is 4.10.0

I have also posted this issue on the cura github, but i doubt they will do much about it.

there was a 3rd line in the code too where it set it to 1.0 which rrf saw as 100%

@resam

im already looking at this, and the min parameter
i would have to change this max parameter any time i want very low airflow

@resam
this flap between scales has ruined a print for me 9 hours in with a not exactly cheap polycarb carbon fibre material

Im not a programmer but am trying to see if i can do a cura post processing plugin to repace any m106 commands less than S1.1 with S0 now

I have a berdair set up on my duet3, and have set the frequency to Q500.

for the printing I am currently doing i need minimal partcooling, mainly on bridges and support interfaces.

i have set 0% - 5% cooling in cura.

3 times during this print the berdair went crazy with 30% 60% and 100% fan

inspecting the gcode generated by cura i think i have found the issue.
2 of the lines pointed below.

I know rrf will take fan control parameter S as either 0.0 - 1.0 or 1 - 255
Cura is generating decimal places on all values above 0
it looks like RRF cannot distinguish values lower than 1 from values above 1 generated by cura so when it sees 0.3 and 0.6 it set my berdair to 30% and 60%

is there anyway to avoid this issue, any parameter to tell RRF which scale that we are using ?

@stephen6309
Thankyou, ill try that