Today and yesterday, I was at #fabcon2016 in Erfurt, Germany. I had the opportunity to show off my DICE and during my presentation I mentioned the tested speedlimits of may little, fast and rigid printer.
After the presentation, I was approached by a listener with doubt of my previous mentioned speed vs the realworld speed.
In my opinion, 100mm/s are 100mm/s.
The person with doubt of my data claimed, that in case of a coreXY system the actual speed of 100mm/s is something like 100mm/s DIVIDED by squareroot(2), so: 100mm/s divided by 1,41 = 71mm/s. And for a delta, he claimed, it is even slower.
So, I want to ask you, what do you know about this? Is this true?
I don’t talk about acceleration, just plain speed in our 3d-printers.
I’m just having a hard time figuring our where the squareroot(2) is coming from. You’re pulley size is the only thing I can think of that would affect whether or not you’re speed is faster or slower…but you end up calculating your speed based off of your pulley size so the size doesn’t matter. Hm…
Without doing any math, I think that this person is not correct. Can your printer print at 100mm/s in the X axis ? Can the same printer print at 100mm/s in the Y axis? Is the processor capable of driving both axis at the same rate of 100mm/s? If so, on the surface, it would seem that the nozzle should be capable of moving at 100mm/s TIMES the square root of 2 or a speed of 141mm/s. Now, when it comes actual, real world output, empirical experiments might be needed to know for certain.
@Blake_Dunham the square root of 2 is from solving a right triangle. A triangle with the two right-angle legs equal to 1 each, has a third leg of length 1.41
He claimed, that for moving a straight X path in a coreXY-system, both motors have to turn. In his opinion, to reach 100mm/s at straight X, the motors have to turn at 141mm/s to reach the x-axis speed of 100mm/s.
They shouldn’t have to for straight moves. For diagonals they might have too.
No. In a coreXY, both motors have to turn for a straight move. Running diagonally needs only one motor. But that’s the point of the discussion!
Marlin’s kinematics have a history of screwing up speeds because the velocity calculation is taken in actuator/joint space rather than Cartesian output space. I haven’t looked at this in a couple years though so I could be out of date. Other firmwares tend to do it right because they didn’t just have the kinematics transform jammed in as an ad hoc kludge like Delta and CoreXY support in Marlin. EGSailfish initially had CoreXY speeds running at sqrt(2) slower, but the bug was fixed about a year ago and now all speeds are commanded feedrates (less acceleration slowdowns).
Maybe @Arthur_Wolf can say something about the kinematic math of smoothieware? The DICE is driven by smoothieware…
@Rene_Jurack I forgot that your DICE is corexy; that changes things somewhat. However, as you mentioned, diagonals should be only one motor or the other. This seems to be more of an issue of how fast you can drive the motors and how the printed part is oriented on the build platform. I just assumed, and maybe incorrectly, that the speed that the nozzle moves is controlled by the slicer and it’s knowledge of your machine parameters. When you ask for 100mm/s, I assumed that the slicer would create the correct G-code to make the move and would therefore drive the motors faster than the print speed if the printer geometry required such.
Print a cylinder, single perimeter, with a diameter of 63.69mm. At 100mm/s it should take 2 seconds (63.69mm * 3.14 = 2s * 100mm/s). Time it for several loops to minimize error in your start stop.
For single motor moves in CoreXY, the XY carriage moves on a diagonal with [true speed = belt speed / sqrt(2)]. This is because the belts are acting through a 90-degree-deflection which is like a compound pulley (eg block and tackle) of ratio 1:sqrt(2). When you run both motors at the same rate to get X or Y axis motion, the carriage speed is equal to each belt’s speed because adding perpendicular vectors of equal length produces output scaled sqrt(2):1. So the square roots cancel out and you get what you’d expect from the naive kinematics understanding.
@Mark_Rehorst cylinders don’t have much (if any) acceleration slowdown because the angle at the segment vertex is too small for GRBL’s jerk or junction deviation algorithms to realize there’s any reason to slow down.
@Rene_Jurack That person was dumb. End of story.
Ok just to be clear : if you ask the machine to move at 100mm/s, it’ll move at 100mm/s, no matter what the arm solution is. That’s sort of the point of actually doing the math …
This is sort of like he was saying that if you ask the machine to move 100mm, it really moves 71mm.
I think this is a case of somebody thinking they are smarter than they really are …
I think this guy confused belt speed with travel speed. Although a straight x or y move uses 2 motors, the firmware should correctly calculate the movement speed and act accordingly. If it were a perfect diagonal move, again the firmware should calculate the movement speed. The differences in the instances is that in a diagonal move the belt speed is equal to the movement, where in a straight move the belt speed is across 2 belts, not 1.
Math makes it work.
@Arthur_Wolf @Stephanie_A I’m pretty sure the guy was just assuming that dumb Marlin behavior is universal across all firmwares. For example, the original Delta kinematics hack that Johann made for Marlin caused speeds to NEVER be correct, since it converted distances to delta carriage travels but did not change the velocity calculation math away from Cartesian carriage motion.
@Ryan_Carlyle Eh that’s right I forgot Marlin did that.
Though the problem was that it applied the planning math to the actuators instead of the effector right ? It did move at the correct speeds, it just did the planning on the wrong thing …
Or did I miss something even worse than that ?
Thank you for clearing things up and giving additional info. I am a little bit relieved right now 
@Arthur_Wolf The net observable behavior was that it Marlin Deltas would print faster at the center of the build plate than the edges. It’s been a long time since I dug into the details, but I think it segmented moves and converted commanded cartesian axis travels to tower travels right after gcode parsing. So all accel/velocity math was subsequently done in virtual tower position space (eg “speed” = sqrt(A^2+B^2+C^2) where A,B,C are tower carriage speeds) rather than using actual nozzle motion.
I’m curious what is the better method, as carriage speed would seem the limiting factor. However in printspace, uneven nozzle speeds mean uneven extrusion because nozzle pressure is not calculated.