On Jul 17, 2011 11:26 PM, "Andrew" <parallel.kinematics@...> wrote:
> 2011/7/18 Viesturs Lācis <viesturs.lacis@...>:
> > I think that this tool length offset should be added/subtracted to
> > tran->pos.z, as well as tran->pos.x and tran->pos.y should be adjusted
> > for sin() of pos->a and pos->b multiplied with the tool offset. And
> > also adjust tran->pos.z for cos() of pos->a and pos->b multiplied with
> > tool offset.
> I thought about that, but there's a problem. When AB change, all XYZ
> offsets will also change. To avoid this you need to introduce W axis
> (like 5axiskins). For now I desided to apply and remove tool offset
> only when AB=0 (anyway tool is changed and measured by tool setter
> in this position). Thus I just add tool offset value to both base and
> platform joints Z position. That changes exactly the reference frame
> origin, i.e. platform's center of rotation.
> I will check it with the machine soon.
> > I have something similar in my robokins, let me know, if You need more
> > detailed explanation!
> Thanks, I'd like to see how you've done this, probably fragments of code.
> > Probably yes - postprocessor might do it better, but I think of these
> > 2 reasons to do it in EMC2:
> > 1) the code is readable and understandable by operator and can be
> > adjusted by hand. If the compensation for tool size is included in X,
> > Y, Z etc words, then it is not possible to completely read and
> > understand the code and to adjust it;
> Most 5axis programs are large and complicated, so the operator has
> nothing to do with them.
During execution of a non tool axis compensated program the xyz references
are the pivot point of the rotary axes. This leads to operator complexity
/confusion. The tool length compensated tool path is the tool tip and
therefore the operator can easily reference where the tool tip is /should be
by looking at the program. The operator may not be able to change the
program but will have confidence of the machine positioning during
> > 2) the whole point of kinematics modules is that You feed in just the
> > "target" coordinate values, EMC2 will do all the job to calculate
> > required joint positions to do it.
> > But the main reason to do it in postprocessor might be the fact, that
> > implementation of this in EMC2 is yet to be done...
> The implementation of 5axis tool radius compensation should also
> consider tool shape, that's not a task for EMC2. But exactly the
> postprocessor knows all data to make required calculations.
I wholeheartedly disagree with this contention. 5axis- cutter comp does NOT
need tool end geometry information - just tool diameter /radius. Any tool
end geometry changes would be of such magnitude necessitating reprocessing
the code generation program, possibly requiring tool path changes.
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> Emc-users mailing list