On Jul 17, 2011 11:26 PM, "Andrew" <parallel.kinemat...@gmail.com> wrote: > > 2011/7/18 Viesturs Lācis <viesturs.la...@gmail.com>: > > 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 operation. > > 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. > Andrew > > ------------------------------------------------------------------------------ > 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. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users Thanks Stuart ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
