RAMPS firmware (G61/G64 ) --Motion Tolerance ?

Hi, all:

I'm a cnc hobbiest, and reprap nut. I have been following reprap for years, and have been working on my own repstrap for a while, though progress is slow. I am by no means an expert, but I have built and operated my own CNC machine. I use EMC2 for control-- it is an excellent motion controller, though unfortunately typically in a much less convenient package size-wise than a RAMPS board

I've noticed that folks using RAMPS tend to print more slowly when they want 'good quality', and more quickly when quality is not as important, or based on the geometry of the object, they know the errors will be low.

There is a better way-- the way emc2 does it. The idea is to set a tolerance ( say, 0.001 inches ) using G64. This tolerance represents to the controller the maximum allowable distance from the programmed path that is allowed. When moving, the motion controller will smooth out corners to the extent allowed by this tolerance, so that speed can be maximized. Selecting G61 selects 'exact path mode'-- which means an absolute stop in each corner to ensure path following error is zero.

EMC calls this feature 'trajectory control' -- more information about it is here. [wiki.linuxcnc.org].

Implementing this feature in RAMPS firmware would have three huge benefits:
(1) accuracy can be easily specified, and you would know without muss or fuss that your machine will build it as fast as possible to that accuracy. This is a huge improvement over trial and error!
(2) overall print speed will be greatly improved, because the trajectory planner will only slow down when it has to-- not when it doesnt. So 'just go slowly in the perimeter' becaomes 'just go slowly when i cannot hold to the path within the specified tolerance without slowing down
(3) it would be possible to embed accuracy rules into the object itself, by embedding G64 commands into the gcode, IE, for this part of of the object, print very accurately, but not for this other part.

I'm not a really great programmer, so i'm posting this idea in case someone who is could possible use the idea. EMC2 source, which includes all of the code ( c) to do this is publicly available at this URL: [git.linuxcnc.org]...


Has anyone investigated this idea? I am sure that the math for doing the trajectory blending is not trivial-- but the source is free to use, so maybe most of this functionality is written already and just needs to be ported?

Nothing new. Discussed many times.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

That's good to hear... am I incorrect then that no firmware has implemenred this, or is there
a good reason it has not been? Can you point me to some of those discussions?
I looked at the links below your post, but they did not appear to contain more info on this topic

Thanks!

In addition to Traumflug's very helpful response...

I can't help with the implementation, but you might want to have a look on the dev list archives, a cursory search yielded this: http://reprap.org/pipermail/reprap-dev/2010-October/001592.html, and from the forums this: http://forums.reprap.org/read.php?147,82384,85269

Might be worth jumping on the dev mailing list and asking there perhaps.

Best of luck

---

------------------------------------------
garyhodgson.com/reprap | reprap.development-tracker.info | thingtracker.net

Interesting-- so the gist of the situation seems to be:
"yes, that would be great, but the calculations are simply too much to do in relatively low power firmware, so the proposal is to do trajectory planning in the pc, and then send lower level information to the processor... but there's no great way to send that data in the gcode itself"

To me, this is somewhat disappointing-- it means that do to good trajectory planning, you still need a computer that is not a single board solution, but emc still has the issue that it needs a parallel port, so its hard to find in a new, small computer

You've read just one opinion of many. If only one person of ten discussing the topic would actually implement something, we'd have EMC-quality look ahead for many months already.

The Grbl folks (an Arduino-based, but non-RepRap firmware) did implement sort of a path planning. At a corner they slow down to what they think is a reasonable speed, then they move the corner without smoothing (and call it "jerk" ). That's what all the newer RepRap firmwares copy now.

Grbl and all RepRap firmwares use the Bresenham algorithm, which makes geometrical accuracy simple, but moving curves difficult.

EMC doesn't use Bresenham, but calculates the wanted position many times, like 100'000 times a second. If the difference between the wanted and the actual position is bigger than half a step, it does a step. Simple concept.

Another approach is to get rid of Mr. Bresenham and calculate all axes independently of each other. Just committed to Teacup: [forums.reprap.org]

If you want to take a peek yourself, all the axis movement stuff is in Teacup's dda.c. dda_start() translates a movement request to something fit for the stepping algorithm, dda_step() does the actual steps.

Oh, and there is no "RAMPS" firmware. Firmwares include FiveD, Teacup, Sprinter, SJFW, Jagon, Repetier and whatever might spring up next week. All these firmwares run on RAMPS as well as on other electronics and vice-versa.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ah, interesting! Yeah emcs default thread runs at 25us I think.

Which approach do you think would be most suitable in the case that we want to handle g02 and g03
in addition to g01? Im still dreaming that someday I will finish my scripts to slice step files instead of
crappy stl files, which could produce arcs on perimeters. If I can get that going,
then the object designer could contol accuract by rounding corners if desired in the object

I have seen some generalizations of bresenham to arcs. I suppose calculating commanded
position becomes much more expensive for arcs...

How difficult do you think it would be to supposrt g02 and g03?

I will have a look at the firmware out there now... but when I do have a chance to write some
code it will be on handling step files. Initial versions of the script have been very promising.

dave.cowden Wrote:
-------------------------------------------------------
> Which approach do you think would be most suitable
> in the case that we want to handle g02 and g03
> in addition to g01? Im still dreaming that
> someday I will finish my scripts to slice step
> files instead of
> crappy stl files, which could produce arcs on
> perimeters. If I can get that going,
> then the object designer could contol accuract by
> rounding corners if desired in the object
>
> I have seen some generalizations of bresenham to
> arcs. I suppose calculating commanded
> position becomes much more expensive for arcs...
>
> How difficult do you think it would be to supposrt
> g02 and g03?
>
> I will have a look at the firmware out there
> now... but when I do have a chance to write some
> code it will be on handling step files. Initial
> versions of the script have been very promising.

I've been working on Jagon, still have some issues that keep me from using it regularly, but i should be able to resolve those with a good test suite.

Anyways, I have been considering using the generalized Bresenham algorithms for drawing arcs. Then if the G61/G64 commands are used, arcs will be drawn to join each line segment depending on the tolerance. Shouldn't be much slower than Bresenham and it will allow for much smoother printing at speed.