Feature Request: Print area shape for Delta printers. Is it possible to make it a triangle?

[MRGiacalone]

Hi,

I experienced an issue with my steppers running sending the carriage to a -416 location using Pronterface and to a -958 location using Repetier-Host. I describe the issue in these links (http://forums.reprap.org/read.php?267,355792; https://groups.google.com/forum/#!topic/deltabot/tUJ1ty6yebg; and https://github.com/RichCattell/Marlin/issues/7in).

The last one shows how to stop the steppers from running wild. The solution is to avoid the carriage from moving to a negative stance, a code that was included in Rich Cattell's branch of Marlin.

The initial problem occurred while testing our Merida Delta moves to have it reach the longest point possible allowed, in our case, by a 270mm Delta arm. This additional reach should be beneficial for Deltas in terms of print area/volume, since it creates a triangular print surface rather than a circular one (actually a triangular shape with rounded corners which we can call a Merida Triangle). However, to account for limits within such triangular base, the Marlin firmware (or any other firmware for the Arduino) would have to do a lot of additional computations. Something that is resolved by just using a rectangular base set by the software end stops.

When a user selects Delta shape in any of the host software, it immediately assumes a circular base. Regardless of the fact that the software end stops are still delimiting a rectangular base. This shows that the host software can override the limits set by the firmware.

If the host is modified to gather information about the Delta to produce a triangular base rather than a circular one, users would be allowed to conform to this triangular array before creating the G-code. This array obeys the limits set by the triangle rather than to have the microcontroller do the extra work.

The max triangular shape is composed of four equal triangles that are defined by the middle triangle. This middle one can be found by simply putting together the three points just in front of each pole (A,B,C). These points are commonly referred to as x, y and z, respectively.

Is it possible to achieve this modification and see them in Pronterface future releases?

[kliment]

Okay, let me clear up a few misconceptions so we can discuss this.

The slicing software generates gcode based on the model and its settings. The host software sends that gcode to the printer. The printer firmware, conforming to its own limits, executes the gcode commands.

The host software cannot "override" the limits of the firmware. When a host shows a circular bed, that circle is contained WITHIN the rectangular limits in the firmware. And if the gcode contains a command that is outside the circle but inside the rectangle it will be executed. The host does not modify the gcode in general.

There are several things that can be done. We can ignore the commands going outside the possible movement area, but if a part of your object is there your print will be useless then. We can enforce the limits in firmware (as you already do) but that would again ruin any object that goes outside them. On the host side, it's at best possible to DETECT when an object is outside those limits, but it's not possible to CORRECT the problem. So the best time to fix this problem is before slicing. Ideally, we'd be able to load a bitmap with the shape of the print area into slic3r and position the object there. Until we have that, I can write a position checker script that checks a gcode file for coordinates that pass through the forbidden area that you can run on your gcode files to get a warning before you try to print them. Does that make sense?

On 05/22/2014 03:04 AM, Marcelo Romero Giacalone wrote:

Hi,

I experienced an issue with my steppers running sending the carriage to a -416 location using Pronterface and to a -958 location using Repetier-Host. I describe the issue in these links (http://forums.reprap.org/read.php?267,355792; https://groups.google.com/forum/#!topic/deltabot/tUJ1ty6yebg https://groups.google.com/forum/#%21topic/deltabot/tUJ1ty6yebg; and https://github.com/RichCattell/Marlin/issues/7in).

The last one shows how to stop the steppers from running wild. The solution is to avoid the carriage from moving to a negative stance, a code that was included in Rich Cattell's branch of Marlin.

The initial problem occurred while testing our Merida Delta moves to have it reach the longest point possible allowed, in our case, by a 270mm Delta arm. This additional reach should be beneficial for Deltas in terms of print area/volume, since it creates a triangular print surface rather than a circular one (actually a triangular shape with rounded corners which we can call a Merida Triangle). However, to account for limits within such triangular base, the Marlin firmware (or any other firmware for the Arduino) would have to do a lot of additional computations. Something that is resolved by just using a rectangular base set by the software end stops.

When a user selects Delta shape in any of the host software, it immediately assumes a circular base. Regardless of the fact that the software end stops are still delimiting a rectangular base. This shows that the host software can override the limits set by the firmware.

If the host is modified to gather information about the Delta to produce a triangular base rather than a circular one, users would be allowed to conform to this triangular array before creating the G-code. This array obeys the limits set by the triangle rather than to have the microcontroller do the extra work.

4trianglesabc https://cloud.githubusercontent.com/assets/7512698/3048514/76d2e02a-e149-11e3-8571-fa06ac245b3c.png

The max triangular shape is composed of four equal triangles that are defined by the middle triangle. This middle one can be found by simply putting together the three points just in front of each pole (A,B,C). These points are commonly referred to as x, y and z, respectively.

Is it possible to achieve this modification and see them in Pronterface future releases?

— Reply to this email directly or view it on GitHub https://github.com/kliment/Printrun/issues/540.

[MRGiacalone]

Kliment,

That does make sense, and I get that no override on end stops is done by the host (with good reason).

So if the end stops do not allow some objects to be printed when they are outside the print area (the one set by the end stops), then for this type of testing with a triangular base it is best to disable them. The ones that might be of use are the Y and Z plane. But the X will not truly show the limits in that plane. To control the moves accurately it will have to be fixed before slicing.

The Slic3r scenario would be the ideal one. Since Slic3r can automatically arrange additional copies to fit a defined area (a rectangular one for now). It should be able to behave in the same way using a different shape as reference.

If one chose to disable the end stops all together, it is possible to position an array of parts in a way that can be accommodated in a triangular area. (assuming a certain level of risk). Your script would confirm/disapprove the array with the specified print area, and thus eliminate that risk.

I hope to be able to run some tests once our Delta is finished. It would be important if other Delta reprapers can do some additional testing. I'll be waiting to try your script and see if other issues arise from the experiment.

Thank you,

Marcelo R G

[iXce]

Hmm, so practically, the thing we could do here is draw a rectangle instead of a circle for such printers ?