@droftarts Perfect, exactly what I was looking for. Worked great for both of my boards. I now have differences (among the sensors) of 0.5 ° C. With the fixed resistors it was only 0.1 ° C!
perfect thank you!

@dc42 said in closed loop nema 17/23 driver/controller for Duet 3 6hc board:

closed loop expansion board under development,

@dc42 When will the closed loop Board be available? Can I already order some

@droftarts Perfect, exactly what I was looking for. Worked great for both of my boards. I now have differences (among the sensors) of 0.5 ° C. With the fixed resistors it was only 0.1 ° C!
perfect thank you!

On my 6HC mainboard all temperature values at 20°C are about 4°C too low (all the sensors are correctly configured with default values). The same sensors show the correct values on the Expansion Board 3HC (with the same parameters). It seems like the reference voltage on my 6HC board is wrong. Can this be checked? Can this possibly be adjusted?

@jay_s_uk said in pre or post code for G-Code:

I think calling of mesh.g is broken in beta 2 with an SBC attached if thats what you have.

I don't necessarily think so ...

In mesh.g I should probably use "G29 S0" (this works).

But if someone calls "G29 S0" directly, mesh.g is not executed ... and the problem is there again.

i agree with you... but this dont work.

my system upgrade to 3.2-beta2 is done.

without a mesh.g file everything is like it was before.

with a new mesh.g file (only one line in it with "g29") i get the error

G29 Error: Push(): stack overflow

maybe a Stack overflow occurs when iu run a recursive macro ?

@Phaedrux said in pre or post code for G-Code:

mesh.g

Thank's - I found this

In RepRapFirmware 3.2 and later, mesh.g is run in response to a G29 command with no parameters. If file mesh.g is not found then it behaves like G29 S0 instead.

I have to update first ..

I'll try it out and give feedback... !

@Phaedrux said in pre or post code for G-Code:

bed.g macro

Thank's Phaedrux - but this don't help. I use this macro already, that's fine - but if someone else call a g29 (eg. a start script from a slicer, or duet's WEB-Interface or...) then - crash..... if a tool is grabbed at this time.

G32 s not a problem - because i can park my tool first in bed.g....

I have to make sure, that NEVER a tool is loaded when a G29 command is executed. Otherwise my system has a mechanical crash...

In my project, I have to park first my Tool before a G29 can be executed.

If a soloution availible to send a pre or post code for a specific G-Command

e.g.

macro-g29.g
T-0 ; park tool
do somthing else
G29 ; execute the real G29 command
do somthing else