Delta firmware and Gcode in the future...

I've started this thread for everyone and I'm hoping that Polygonhell and Martinprice and others will participate in the conversation.


Basically I just want to openly brainstorm possible directions to take concerning deltas.


I'll start here: It seems there are 3 options available for controlling a delta
1. The existing "hacks" on top of marlin and repetier that calculate and translate into something the firmware can use.

2. A new flavor of Gcode meant specifically for deltas. (someone else mentioned this)

3. A firmware that could do real time calculations on the fly almost in a "read-ahead" fashion


I feel at this point in time, being a couple years away from more powerful electonics/controllers, real time delta firmware may be a bit of work.

But how hard would it be to use a firmware that accepts G-code meant for linear deltas, and alter our .gcode to work? This provides two advantages. 1) There is no extra processing required for the firmware, 2) We already have to process our .stl's anyways, doesn't it make sense to either slice into delta-native gcode or wash the gcode to change it into necessary code for our hypothetical firmware?

With a relatively simple script XYZE gcode could be changed into a ABCE? setup and fed in absolute values directly to the firmware. This should eliminate some of the issues that exist right now, as the firmware won't be doing any extra work, it would already be done in the Gcode.
The maths for this while complicated to me, shouldn't even take too long to process a file, especially if in the future slicing software could produce the native gcode itself.


Ideas? suggestions?
(I apologize if some of my terminology is improper)

xclusive585 Wrote:
-------------------------------------------------------
> I feel at this point in time, being a couple years
> away from more powerful electonics/controllers,
> real time delta firmware may be a bit of work.

Maybe closer than you think? I have been looking closely at Due and RAMPS and have decided there is very little that needs changing, so I am just going to go ahead and plug in a RAMPS to my Due. Firmware will require some porting, but I have done two ARM implementations (working on a third) so I think I have a good handle on that.

> so I am just
> going to go ahead and plug in a RAMPS to my Due.
Don't do that with a stock (5V) RAMPS: it may damage the (3.3V) Due (by overvoltage at input pins) and/or the heater MOSFETs (by turning them only partly on so they overheat).

However, I agree that designing a modified RAMPS to work with the Due is a good idea.

Gen7-ARM exists already, as do 4pi and smoothieboard.

Regarding special G-code: this won't help you. Delta bots require non-linear motor movements, so you have to recalculate the Bresenham values after each step to do it "right". No idea how many CPU cycles this requires, but if you try, you'll find out. At worst, you're pretty limited in maximum speed.

The good news: once you found out how to do the calculations, it's easily portable to more powerful CPUs.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Luckily deltas only produce quadratic arcs, so what you would probably do is adjust velocity per step, and adjust the step rate accordingly.
I suspect that sounds easier than it is, I haven't looked at the actual step output code in any of the major firmwares.
On the plus side it would make G2 and G3 really easy to implement properly.

rebecca.palmer Wrote:
-------------------------------------------------------
> > so I am just
> > going to go ahead and plug in a RAMPS to my
> Due.
> Don't do that with a stock (5V) RAMPS: it may
> damage the (3.3V) Due (by overvoltage at input
> pins) and/or the heater MOSFETs (by turning them
> only partly on so they overheat).

"Don't" is good advice Enthusiasm nearly got the better of me. If I remove the 5V pins from the RAMPS, and connect it's VCC to 3.3V, I think I can get the steppers, mechanical endstops and thermistors to work OK. I will remove the MOSFETs and add some external cicruits so I can play with some new gate drivers.

>
> However, I agree that designing a modified RAMPS
> to work with the Due is a good idea.

If you have any comments on [reprap.org] please let me know. I am pursuing both a RAMPS-3V3 and an interface shield, as that would possibly allow people to reuse existing RAMPS boards rather than buy new ones.

I have captured some schematics in Kicad, I will try to post them to wiki/github this weekend.

I have also developed a firmware variation for non-cartesian geometry (Marlin-SCARA).

xclusive585 Wrote:
-------------------------------------------------------
> I'll start here: It seems there are 3 options
> available for controlling a delta
> 1. The existing "hacks" on top of marlin and
> repetier that calculate and translate into
> something the firmware can use.

I used this approach and I believe that it's a perfectly valid way of handling the non-cartesian printer geometry, and should not be called "hack" at all.

The only major drawback is the extra processing power required. This may limit the maximum speed (especially on something as low powered as an AVR) but whenever this isn't an issue, I really don't see any other significant drawbacks.

> 2. A new flavor of Gcode meant specifically for
> deltas. (someone else mentioned this)

This would be essentially the same as the first approach but the mapping between coordinate systems would just happen at a different place. Both the slicer and the print frontend software would have to understand the specific printer geometry and subdividing all the straight movements in the print into small segments would totally saturate the serial link. You would have to push the Gcode through ethernet or upload it onto printer's local memory. And in the end the firmware's path planner would be handling the same converted coordinates as in the first approach, producing the exact same movement.

This avoids the drawback of the first approach but introduces several others.

> 3. A firmware that could do real time calculations
> on the fly almost in a "read-ahead" fashion

I assume that this is the approach where the path planner and motion control get cartesian coordinates and then generate the stepper pulses so that the printer moves correctly in the printer's non-cartesian geometry while taking acceleration, coordinated axis movement etc. into account? Sounds challenging, to put it mildly, just from a coding point of view.

It would probably be the best way to control a non-cartesian printer in a theoretical sense, though... producing the smoothest motion. Still.. I don't know if the Delta geometry is significantly easier, but I really don't want to try to embed the following SCARA conversion into the lower-level planner/control code...

float calculate_arm_rotation(float x, float y, int arm_num)
{
  float rot;

  // Calculate the first arm segment rotation away from the line between the 
  // base axis and target point.
  rot = acos((SCARA_SEG1_LEN*SCARA_SEG1_LEN - SCARA_SEG2_LEN*SCARA_SEG2_LEN 
              + (x*x + y*y)) / (2 * sqrt(x*x + y*y)) 
             / SCARA_SEG1_LEN) * 180 / M_PI;

  // From the relative rotation, calculate absolute rotation, taking the
  // arm number into account to get the elbow rotation on the correct side.
  return -((arm_num == 1) 
           ? (atan2(y, x) * 180 / M_PI + rot - 90)
           : (atan2(y, x) * 180 / M_PI - rot - 90));
}

ttsalo Wrote:

> I don't know if the Delta geometry is
> significantly easier, but I really don't want to
> try to embed the following SCARA conversion into
> the lower-level planner/control code...

Yes for the Rostock design (or any other with linear motion driving one end of the rods) any motion is a conic, there are bresenham variants that will deal with this, or you can do it with two DDA steps.
It's pretty much just a variation of what would be required to support G2/G3 in the planner.

The issue with the existing solution, "hack" or not is the interaction between trying to add many small linear segments to the planning buffer while trying to drain it, there seem to be cases where the buffer starves of data mid move causing pauses, both Repetier and Marlin do this infrequently (Marlin seems to do it more frequently), and it's worse of slow moves because both use time to target as the metric for the number of segments to add. It probably wouldn't be an issue if the AVR was faster.

Edited 1 time(s). Last edit at 02/13/2013 06:08PM by Polygonhell.

I also think we should keep a close eye on the Deltamaker people. If they do anything to that firmware that they release into their product, they have to share with us. :-)