@t3p3tony email has been sent.

@thedragonlord said in Confused about tfree#, tpost#, tpre#:

what's driving me crazy is that I'm not able to make the M116 to work...the file goes on without waiting...

Mine waits for the heater, but my file does not have all the other stuff in it.

Try just M116 without anything else around it, as T3P3Tony says.

I suspect things like the if global.isActuallyPrinting==true line will always fail at a time like a toolchange, as it is not literally printing (extruding or moving to a new extrude position) at that instant.

@t3p3tony
Totally forgot about that setting. I found a thread about a thermistor similar to mine and punched in their values and now I get 1% accuracy at 200 degrees and 2.7% accuracy at 300 degrees. Works for me!
Probably was just a bad thermistor.
Thanks so much!

@garth_42 you can test if this is an issue with the timing/formatting of your network request vs what is been reported by making a move and using echo command to report what the printer status is during the move. very simplistically:

sent: echo state.status received: idle

then

sent: G1 Z25 F2000 sent: echo state.status received: busy

this is just using the console in DWC

@fbg please email info@duet3d.com.

@heki so in rough outline the data flow is:

read from input (SD card, USB, Network, UART etc) process (buffer, plan, step generation) step output to motors

The difference in SBC mode for commands coming from the SBC is the input stage can be intercepted and logged/used in some way. Other than that the Duet is doing the processing and step generation.

What exactly do you need to collect?

Whole moves? individual steps? something in between?

You may be able to get what you need but running a move, capturing the accelerometer data as we do already and then processing it after the fact. then running another move. After all you know the move you commanded, and you know the accelerometer response.

@pickett may I ask why you need a picture of the back of the board ? If its for the labels then the wiring diagram is here:

https://duet3d.dozuki.com/Wiki/Duet_3_Mini_5plus_Wiring

none the less here is a render which is easier to use than an actual picture and I don't have any HQ pics of the back square on to hand.

843b3da7-f66e-487e-b500-e92780b25f11-image.png

@joergs5 I had a similar idea, when I saw the RasPi Pico (RP2040) it has several SPI channels at 133MHz and could also act as Co-Processor or toolboard

@deckingman Oh right yes yes thank you. Similar concept, but different need.

Thanks everyone for the swift replies!
Exactly the answers I needed.

@t3p3tony @dc42 Hi

I tried lowering the S value from S5 to S1 in increments of 1 and these seemed to make the issue more apparent each time, so i then adjusted upwards settling on a value of S8 which so far after testing the home position roughly 30x seems to provide a good solid repeatable homing position, I’m super happy with it now!

Thankyou for you’re replies, I really appreciate the help

Thanks

Tom

@t3p3tony yes OK thanks very much 👍😃

@siam thanks👍

@peirof

If you have 2, 3 or 4 independent Z steppers RRF firmware can do Automatic Bed Leveling (ABL) as you described, where adjustments are made to individual Z steppers to get the bed as level as possible.

Also the firmware can do Mesh Bed Compensation (MBC) which involves probing the bed in a grid and gathering data about Z adjustments that need to be made in real time during printing.

The two features are independent.

All of my printers use MBC but only one of them has multiple Z steppers (3) to allow use of ABL.

The two

ths🙂

@alastair1 with everything working in a steady state then future stable->stable upgrades should upgrade all the expansion boards as well.

@dogma2k possibly. a parser is often used to get information from a http reply. you still need to send the right commands to the duet.