So a build area of a delta printer is a spherical cone due to carriages hitting end stops, but slicers portray this as a cylinder… Is there any way to figure out if an end stop will be hit? Is there a way to portray the actual build area?
It’s essentially a cylinder. Yes, there’s a small, oddly-shaped area available above the top of the cylinder, but unless your delta’s arms are really too short for its radius, it’s not enough space to be worth worrying about.
My worry is printing the size of the bed and it not being able to reach all the way out near the end
Move one carriage all the way to the top. Move the others so that that arm points straight down. Measure the distance from the nozzle to the platform. That’s your maximum height, and a full cylinder of that height is all usable space.
Now that’s how the slicer should calculate build area. Right now it uses the distance when all 3 axis are homed
Yeah, that will give you a higher point, which is technically the highest point you can reach, but only in the very center. If the slicer also knows the arm length and delta radius, it can calculate the actual bounds from that, but I’ve only seen them use the cylinder method, in which case it should be measured as I described.
Time to write a suggestion to slic3r 
For reference, check out the discussion (including some pictures) here: https://github.com/MarlinFirmware/Marlin/issues/2953
Link doesn’t work
Works for me…
Weird. Now it works
So, those calcs are happening in the slicer? I’ve been looking into a custom build, and that was one of the questions I have been meaning to ask. Can you program in new geometries into the slicer?
@Neal_Grieb As far as I’m aware, no, none of the slicers are doing it. They just define a cylindrical build volume.
Ok, I was under the impression that the gcode just gives a position, feed rate, and acceleration/speed. I suppose I should beak open a gcode file, and check it out.
@Neal_Grieb Yes, that’s more or less what gcode does. The problem comes when you have a position that the printer can’t physically reach. On a cartesian bot, you can create software endstops to prevent this, but the thread I liked to was a discussion of how to implement the same thing with a deltabot. With complicated mechanisms like those in a deltabot, this is not as easy as just defining minimum and maximum coordinates to ensure that parts don’t crash into one another, and you need to do either some more complicated math or limit the build volume to a simpler subset of what the machine can actually reach.
I’m sure someone has predefined these extents using a simple code somewhere with variable input lengths…if not I’d be happy to do so. Might be a fun challenge, and I’m going to have to do this for my design anyway.
On the firmware side, the problem is that it involves some math that is pretty taxing on an 8-bit processor (which, on a deltabot, is already running pretty close to its limits).
On the slicer side, the problem is that it requires the slicer to know a couple of extra pieces of information about the printer, which the slicer normally does not need to know. It also requires the slicer developers to understand delta kinematics in a way that they wouldn’t otherwise need to.
@Alex_Xiang yes, I will gladly test your filament
@Alex_Xiang I would gladly try your filament and write a review but I will not buy it. This is not a means of advertisement for your brand