Enhanced Machine Controller

2011/7/17 Andrew <parallel.kinematics@...>:
>
> Can existing pin motion.tooloffset.z be used instead?
> How can I get its value in kinematics file?

Of course, You can!

Create a HAL pin in Your kinematics module and arrange all the
inverse/forward kins calculation.

And then in HAL file instead of setting a certain value for that pin
You should just link it with motion.tooloffset.z
I have been using the first option - creating HAL pins and then set
certain values in HAL file in kinematics module for welding robot,
waterjet machine and some other test modules as well. Creating a HAL
pin requires adding less than 10 lines (I think that 5 or 6 is enough)
to the kinematics module. Take a look at pumakins for how it is done.
Let me know, if You cannot manage that - I will try to find and share
one of my implementations.

I think that tool radius compensation also is related to this question
- if tool is tilted, then length of projection of tool's radius on the
surface of material also changes (except for tools with round
tooltip). Probably You might want to take into account also this
aspect.

Viesturs

2011/7/17 Viesturs Lācis <viesturs.lacis@...>:
> Create a HAL pin in Your kinematics module and arrange all the
> inverse/forward kins calculation.
>
> And then in HAL file instead of setting a certain value for that pin
> You should just link it with motion.tooloffset.z
> I have been using the first option - creating HAL pins and then set
> certain values in HAL file in kinematics module for welding robot,
> waterjet machine and some other test modules as well. Creating a HAL
> pin requires adding less than 10 lines (I think that 5 or 6 is enough)
> to the kinematics module. Take a look at pumakins for how it is done.
> Let me know, if You cannot manage that - I will try to find and share
> one of my implementations.

Thank you, Viesturs!

I managed to create a pin and link it to motion.tooloffset.z. For the
beginning I just added TLO to platform joint coordinates, but it's not
that simple. I have to think more about correct offset
implementation... it should only influence the rotation point. I'm
afraid it should be similar to 5axiskins with extra W axis. I do not
like this way at all.

> I think that tool radius compensation also is related to this question
> - if tool is tilted, then length of projection of tool's radius on the
> surface of material also changes (except for tools with round
> tooltip). Probably You might want to take into account also this
> aspect.

Yes. But such things better be handled by postprocessor with EMC2 tool
radius compensation off.

Andrew
http://parallelrobots.blogspot.com/

2011/7/17 Andrew <parallel.kinematics@...>:
> I have to think more about correct offset
> implementation... it should only influence the rotation point. I'm
> afraid it should be similar to 5axiskins with extra W axis. I do not
> like this way at all.
>

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 have something similar in my robokins, let me know, if You need more
detailed explanation!

>
> Yes. But such things better be handled by postprocessor with EMC2 tool
> radius compensation off.
>

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;
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...

Viesturs

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.

> 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.

Andrew

Hi,

I've been following the thread, I think that was the piece that I was
missing in my kinematics.

Thank you.

In the past I had problems (BANGS) with non-matching initial
conditions for Cartesian an joint coordinates, those problems got
solved for me when I settled up my kinematics, so that when the
hexapod joints toke the value 0 all the Cartesian coordinates (XYZABC)
toke as well the value 0 as well.

I wonder if any special care should be taken when the tool_length is
changed with GCODE or if a nonzero value is automatically loaded on
start-up.

Thank you

Javier

PD: A possible minor bug in 5axiskins

Shouldn't

haldata = hal_malloc(sizeof(struct haldata));

in

rtapi_app_main

have a corresponding free in

rtapi_app_exit

???

On 18 July 2011 13:14, Javier Ros <jros@...> wrote:

> Shouldn't
> haldata = hal_malloc(sizeof(struct haldata));

> have a corresponding free in
>
> rtapi_app_exit

There is no hal_free, hal_mallocc-ed memory is automatically freed
when all hal modules unload.
http://www.linuxcnc.org/docview/html/man/man3/hal_malloc.3hal.html

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

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
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@...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Thanks
Stuart