Re: [Emc-users] Tool length offset for non-trivial kins
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 ??? -- 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
Re: [Emc-users] Tool length offset for non-trivial kins
On 18 July 2011 13:14, Javier Ros j...@unavarra.es 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 -- 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
Re: [Emc-users] Tool length offset for non-trivial kins
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
[Emc-users] Tool length offset for non-trivial kins
Thinking of true 5-axis machining with hexapod, I found that important thing here is how EMC2 handles tool length offset. With XYZAB kinematics I'd prefer to always have AB rotations around TCP. But it proved that setting Z tool offset does not change the rotation center (obviously genhexkins is not aware of TLO at all). The question is how to use TLO data in kinematics file? I see that in 5axiskins it is done some way, they create hal pin result = hal_pin_float_new(5axiskins.tooloffset.z, HAL_IN, (haldata-tool_length), comp_id); but I can't completely figure out how it works. Can existing pin motion.tooloffset.z be used instead? How can I get its value in kinematics file? Andrew http://parallelrobots.blogspot.com/ -- 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
Re: [Emc-users] Tool length offset for non-trivial kins
2011/7/17 Andrew parallel.kinemat...@gmail.com: 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 -- 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
Re: [Emc-users] Tool length offset for non-trivial kins
2011/7/17 Viesturs Lācis viesturs.la...@gmail.com: 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/ -- 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
