@apak
Thank you for the solution. ❤

@tkln I guess, that's not doable right now, but you could try sensorless homing for one of the motors on each tower.

Programming Z probes connected to expansion boards is not yet supported. For now you need to temporarily connect the Smart Effector to the main board if you want to change its sensitivity. I've logged this issue: https://github.com/Duet3D/RepRapFirmware/issues/815

dc42 created this issue in Duet3D/RepRapFirmware open Support programming Smart Effector sensitivity when the effector is connected to an expansion board #815

@dc42
the math they use calculates the leg(s) length first and then replace that by the required servo angle and even the microseconds for PWM duty cycle.
That's the point where it gets specific and needs new formulas. Either for industrial servos or for Deltastyle tower arrangement with steppers.

Beside that difference it's quite the same: both systems have a fixed base/frame and a moving platform connected by six rods.

@breed No need for a heated bed I am printing ceramics

@jasperg that kinematics isn't currently supported in RRF but it could be added. There is a brief overview of how to add new kinematics at https://github.com/Duet3D/RepRapFirmware/wiki/Adding-New-Kinematics. It would probably be possible to implement it as segment-free kinematics.

It actually started working way better with PLA as a side effect

IMG_20220122_190044__01.jpg

@norwestie said in Carriage won't reach bed:

@droftarts said in Carriage won't reach bed:

M665 R134.4 L271.5 B116 H283

Thank you again. This is all Greek to me so I rely heavily to you and the community for help.

i am greek and most of these looks greek to me to ....

the M665 is what defines a printer as a delta to my understanding.

M665 Rxxx( is the radious of ur builded printer the internal one), Lxxx( the length of the rods that hold ur effectors) Bxxx( is the radious of ur bed) abd Hxxx( is the height of ur nozzle to the bed when the limit switces are enabled) .

@dc42 Yes, that is what I thought as well.

Do you have any idea why timing is so far off? Like I mentioned above, I successfully tested these motors with the same power supplies and a MKS SGEN controller board with timings of 3:3:6:6. The MKS SGEN board provided 3.3V logic, so if anything I would have assumed it would need more time to activate the opto-isolators due to the underpowered signal.

One concern I have is these motors are supposed to run at a maximum pulse frequency of 250 kHz. Is there a way for me to set that for the Duet board?

@dc42 yes 🙂 already printing parts

RIP delta but now i cant wait to saw it in half^^

would it not be easier to do it in the slicer?

I wanted to add this has been a educational thread for me as to some of the constraints on Delta designs.

I don't know if I would switch to a smart effector over the SE300 but a revision that includes this would make me give consideration to losing the print area outside the triangle of the towers.

here is another idea.

print these https://www.thingiverse.com/thing:2519593
they will also provide good noise dampening.

now you have space underneath the delta where you can mount the duet without interfering with the motors.

@bassco How did you configure the Smart Effector for Klipper?
I can't seem to find any info on it 😞

This is my current config:

[probe] pin: PC1 z_offset: -0.1

The wiring was okay and was in working order before going Klipper, so that's not a problem.

@taconite said in bed mesh compensation unclarity:

Question: Why is it not possible to load a previously saved height map, without establishing the Z=0 datum? Because of the homing of the axis the position of Z=0 should be the same (Ignoring possible jitter in the homing switches).

on a delta this should still work. if you just ignore the message you should be able to print just fine.

Hi ! I know you've solved the problem you initially asked about. I'm wondering it you could give my some info on how tricky putting a Duet board on a WASP delta was? I have a WASP 60100 (build 2017) and would love to upgrade it with a Duetboard and maybe a E3D Volcano hotend. But, I'm not really sure what I'm getting myself into 🙂 Would you mind me asking a couple of newbie questions about your process?

As @carlosspr says. For stall detection to work, the feed rate in your G1 S1 commands must be at least (60 * m915-h-value / full-steps-per-mm) . If your printer has 80 steps/mm @ x16 microstepping, that's 5 full steps/mm. You are using H200 in M915, so the minimum G1 S1 feed rate would be (200 * 60)/5 = 2400.

@dc42 I checked the belts and they all seem tight. My joints are these plastic ball cup arms and seem to have no binding to them when moved. I think it might be my carriages or the motors. I emailed seemecnc to see if they had any suggestions.

I’m at my wits end with this. I have tried to run the mesh with the hotend off and on. Tried adjusting the delta radius and arm length but I keep seeing these ridges caused by backlash somewhere. I just can’t quite figure out where

Sure, if using the wrong rod length gives you a flat bed height map and good linearity, go with it. It's probably helping to compensate for a geometrical error elsewhere in your printer.

Hi @Gary,
I forgot to upload my solution to this thread, because luckily I've been able to solve it.
It turned out to be simpler then I first assumed. Basically, the error occurred due to another error in the measurements in calibration. This was then stored in the override.g file. I was suspecting that there might have been an error there, but each time I tried deleting it, it was already stored in the machines RAM.
Here is a step by step guide, explaining how I fixed it:

Temporarily delete/comment out the M500 command in the bed.g file. (It causes the machine to store the new values after calibration) Delete the config-override.g file and do an emergency stop of the machine. Restart it, (hopefully there shouldn;t be a config-override.g file) and add the M500 command back in, then perform a delta calibration.

This should have: removed your previously stored values in config-override.g for good --> allowing for new values to replace them, so the printer will home properly.

Also, you don't need the G92 command, it was only a temporary fix

@phaedrux Lack of layer shifts aside, I would say that the print quality is as good if not slightly better than it was before. I have only run a couple of small calibration prints so far but I do intend on printing a Sir Layers-A-Lot with a filament sample tonight or tomorrow.

@adrian52 good to know!