@Exerqtor that's not to say you can't use daemon.g to monitor the inputs if you wanted to and adjust it that way. a loop every couple of seconds should be sufficient so its not going to be a big additional load.

@laakti from the top of the printer, the organisation of the steppers should be as follows

back l Y r e / \ i f X-----Z g t h front t

Please see https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_linear_delta for the in depth documentation on setting up a delta and https://docs.duet3d.com/en/User_manual/Tuning/Delta_calibration for the ensuing calibration.

you may want to refer to http://boim.com/DeltaUtil/CalDoc/Calibration.html to understand typical error cases and how they would affect the mesh, to address them.

@Prabhu-K
See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m950-create-heater-fan-spindle-or-gpioservo-pin
M950 with a K parameter is for defining spindles, it doesn't relate the pin to the probe, so remove them from your configuration. As @Phaedrux says, the second servo pin should have S1 in it. So those two lines should be:

; Z-Probe1 M950 S0 C"duex.pwm5" ; create servo pin 0 for BLTouch 0 ... ; Z-Probe2 M950 S1 C"duex.pwm4" ; create servo pin 1 for BLTouch 1

Also, you will need separate deployprobe and retractprobe for each probe. See https://docs.duet3d.com/en/User_manual/Tuning/Macros#bed-probing

If you have more than one Z probe, then use deployprobe0.g and retractprobe0.g for probe 0, deployprobe1.g and retractprobe1.g for probe 1 and so on.

deployprobe0.g

M280 P0 S10

retractprobe0.g

M280 P0 S90

deployprobe1.g

M280 P1 S10

retractprobe1.g

M280 P1 S90

Ian

@droftarts okay, thank you.

@wbrokow1

Check this link to M140

Frederick

@jay_s_uk Thank`s for your support!!!!!!!!!!!!!!!

Thanks guys!
Actually lowering made it worse so I raised it and found the sweet spot at Q7000 which lets me go down to 20% power while under that it shuts off which is perfect for my needs!

Appreciate the help!

@KeithW I had plans to redesign the sherpa mini in such way that the stepper motor sits below the 50 teeth gear (not above).
That would lower the COG but extend the length between filament gears and hotend. It's a pest or cholera decision...

The tilting adapters would raise the sherpa/orbiter even more.
Maybe a combination of both is the golden way?
I hate doing CAD, so I won't try it until I had to.

The Scewder runs on a BLDC motor, that's why it isn't very popular.
I had to add a step/dir interface and a simpleFOC compatible driver to make it work with RRF.
But the BLDC motor is worth it.
The rollers are available at alixprss

All motors sorted, all endstops are 3.3V, LED strip is 12V, and the camera is a USB camera, you just need to solder on a type A plug. Reusing the ethernet socket to the PI and will add exterior USB sockets for keyboard and mouse.

Looked into reusing the boards on the hotend but it is a mess of components including a soldered on Arduino Beetle! Will run extensions for the fans. I have ordered PT1000 sensors from E3D to replace the thermocouples in the hotend.

Will tidy wiring once everything is proven on the bench!

20240109_150534.jpg

@droftarts Hello Ian,

thank`s a lot for your great support. The boards had different RRF.
Both 3HC had RFF. 3.4.4 and the mainboard RRF.3.5.5. But the main problem was that the conditional code was not indented after the statement.

Best regards

Fabian

Tool fan and part fan are the same thing. The white fan is your heat sink fan.

Even if the heat sink fan wasn't working great you'd likely get stringing or clogging but not weird temp excursions like that.

You can write a macro that will wait for some user action and then call it from the places where you want to stop halt your tested macro.

https://forum.duet3d.com/topic/12897/wait-for-input
https://docs.duet3d.com/User_manual/Reference/Gcodes

@T3P3Tony said in Formnext 2023:

@LayerStacker it was this design, the instructions include how to just have the bottom half:https://www.teamfdm.com/files/file/612-mini-stealth-orbiter-20/

Thank you so much! I did come across that one but obviously didn't look closely enough. Thanks again.

@soare0 Yes, it was a bug in 3.4.6.
I updated all the boards to 3.5.0/1 rc2, and for now, all works.

Thanks for all.

@jay_s_uk
Yes, they cant be controlled, but they will have set in config.g the threshold at wich to start running, wich is ok.
Besides, RRF did it, not me... 👼 Without RRF, I could not have make heads or tails of the configuration files.
However, based on your advice, I will redo this, somehow...

Anyway, I updated all the firmware files to 3.5.0 (6XD, 3HC and Panel Due). My Panel Due, being version ... 1 I guess (it is nothing written on back, beside 7i), needed some effort for it (needed to change the name and to manually press buttons on it), but was ok, too.

Long story short, the problem with buttons is gone, and best of all, the machine is printing now.
As I had other issues with Panel Due, I will check them all.

Thank you.

@achrn it's a fair point. Any sort of user extras that get a bit too complex for conditional gcode maybe well served by plugins built to run on the Pi. I would have thought it was also less risky as you stand less chance of knackering safety critical stuff - unless of course you send the gcode to do so in error.

Has the duet firmware got to the stage where safety critical gcode instructions are locked mid process? Eg changing temp limits, PID settings etc?

@jay_s_uk I got it one year ago.

@dc42 The upgrade to 3.4.6 did the trick, thanks for the suggestion!!!

Problem solved 🙂

@Micha-1 RepRapFirmware benötigt die SD-Karte, da sich darauf sowohl die Konfigurationsdateien (config.g, Macros für homing etc.) als auch die Dateien für das Web Interface befinden.