Executive Summary - Speed to be dependent on distance from centre
The speed is defined by mm travel of the head. This is proportional to the motor speed for a XYZ printer, but other formats have a nonlinear relation. When a delta printer gets to periphery of its travel, one of the motors has to move large distances to move the head a small amount. To fully utilize the speed of my delta, I would like speed to be adjusted by a factor dependent on distance away from the centre. This way a higher speed can be set overall. I have had print failures because the speed is too fast at the periphery for one of the motors.
A few implementation thoughts: All long moves (say >10mm) are divided up, so no move (travel as well as print) is greater than 10mm. The speed given as travel speed is factored downwards by a function dependent on the one of the endpoint's distance from the centre.
(I read somewhere that the main developer has no delta to experiment on - should I post some YouTube stuff?)
Delta Specific Speed Control
- lonesock
- Posts: 258
- Joined: 09 Nov 2014, 18:41
- Contact:
Re: Delta Specific Speed Control
I get it. I assume this is mostly (exclusively?) for travel moves, since they tend to be much faster than extruding moves? Can you give me an idea of a maximum head velocity as a function of distance from center?
Jonathan
Jonathan
- Msquare
- Posts: 20
- Joined: 18 Dec 2014, 12:58
- Location: Copenhagen
Re: Delta Specific Speed Control
Hi,
sure, I can give a first suggestion
it's a triangle problem, just like in school
But as the spread sheet has been invented, I need not bother with the formula
Distance from centre; relative speed of motor for 10mm move compared to centre
-80; 2.55
-70; 2.2
-60; 1.93
-50; 1.71
-40; 1.52
-30; 1.36
-20; 1.23
-10; 1.11
0; 1
So with this enhacement request, I could set the head speed to double at the centre, and then let it be halved as it gets to the edge, where I then have the actual high speed. I do not now if the head speed change (as opposed to the motor speed change) will be so detrimental to printquality that the feature is not as usable as oe might think first.
I tried to do some experiments with some simple handedited Gcode to "shake" the head et the middle and at the edge. It seems to me by the sound of the steppers that the firmware limits top speed. (well, I can view the firmware) I did not get head detachment, but it shaking in empty air is not the same as pressure on extruder and dragging a nozzle in sticky PLA. Lots of tiny movements when printing small details may also be more stressing (almost vibrating) than the relativly large ones I coded.
Anyhow, if I had a choice I'd rather have free positioning of components or layer-slicer-parameter-adjustement than the delta speed compensation.
sure, I can give a first suggestion
it's a triangle problem, just like in school


Distance from centre; relative speed of motor for 10mm move compared to centre
-80; 2.55
-70; 2.2
-60; 1.93
-50; 1.71
-40; 1.52
-30; 1.36
-20; 1.23
-10; 1.11
0; 1
So with this enhacement request, I could set the head speed to double at the centre, and then let it be halved as it gets to the edge, where I then have the actual high speed. I do not now if the head speed change (as opposed to the motor speed change) will be so detrimental to printquality that the feature is not as usable as oe might think first.
I tried to do some experiments with some simple handedited Gcode to "shake" the head et the middle and at the edge. It seems to me by the sound of the steppers that the firmware limits top speed. (well, I can view the firmware) I did not get head detachment, but it shaking in empty air is not the same as pressure on extruder and dragging a nozzle in sticky PLA. Lots of tiny movements when printing small details may also be more stressing (almost vibrating) than the relativly large ones I coded.
Anyhow, if I had a choice I'd rather have free positioning of components or layer-slicer-parameter-adjustement than the delta speed compensation.
- lonesock
- Posts: 258
- Joined: 09 Nov 2014, 18:41
- Contact:
Re: Delta Specific Speed Control
These three features will most likely not make it into the 1.5 release. Both the manual part placement, and the settings as a function of Z would require a bunch of new code, and a bunch of testing. Setting a speed multiplier as a function of radius is moderately straight-forward, but I am trying to wrap this up and get an official build out as soon as possible!
[8^)
Jonathan
[8^)
Jonathan
- Msquare
- Posts: 20
- Joined: 18 Dec 2014, 12:58
- Location: Copenhagen
Re: Delta Specific Speed Control
Yes, a new proper release.
For this feature, the chopping up of log moves to small moves is needed, too, to avoid a long move across half the plate crossing lots of "speed zones".
For this feature, the chopping up of log moves to small moves is needed, too, to avoid a long move across half the plate crossing lots of "speed zones".
-
- Posts: 33
- Joined: 28 Jan 2015, 22:24
Re: Delta Specific Speed Control
This is a great idea. I would say to implement it for both printing and traveling moves, since you don't know if someone's going to try out their delta printer's advertised "200mm/sec" speed by typing that into both the printing and travel speed boxes. The carriages can get CRAZY fast even at reasonable speeds like 50mm/sec! At some point, you will lose steps and hear uncomfortable grinding noises, or the high-pitched whine that means "I can't spin that fast."