Hello Let me summarize what we know: The scarakins.c does not work in case of homing is necessary. Linuxcnc confused with axes at homing because of the linuxcnc 1:1 mapping from axis to joint.
I remapped axis C to A in scarakins.c and modified scara config accordingly. I tested changes on a robot. I uploaded it to https://github.com/BenceKovacs/linuxcnc-mirror/ to branch scara-fix. Please review it. Andy: Another solution for the issue would be to remap joint3 to joint 5 in scarakins.c and modify scara config accordingly. In this case a real 6 axis machine have to be configured from which 2 axes are not in use. It would make not just the config confusing, but also the homing and continuous display of 2 additional axes. The other solution seems to be clearer for non-trivial kinematics machines, where ‘a-b-c turn around x-y-z’ usually doesn’t work anyway. Thanks, Bence 2012/10/24 Bence Kovács <[email protected]>: > Hello > >> I haven't looked at this in any detail, but it would possibly make >> more sense to leave scarakins as an XYZC kinematics, but to map axis C >> to joint 5. >> However I think that might leave us with spare axes in the display. > > It does not work for me either. > > As you wrote, linuxcnc has 1:1 mapping from joints to axes, where > world->c is mapped to joint[5]. I think it does not work because > scarakins.c does not calculate with this mapping problem: > > Scarakins inverse kinematics: > joint[0] = q0; > joint[1] = q1; > joint[2] = D1 + D3 - D5 - z; > joint[3] = c - ( q0 + q1); ////////// joint[3] > joint[4] = world->a; > joint[5] = world->b; > Scarakins forward kinematics: > world->tran.x = x; > world->tran.y = y; > world->tran.z = z; > world->c = c * 180 / PM_PI; /////////// axis C > > world->a = joint[4]; > world->b = joint[5]; > > I understand your point about axis naming, but using world->a seems to > be a straight forward solution of this issue. Correct me if I am wrong > somewhere. > > Bence > > > > > 2012/10/23 andy pugh <[email protected]>: >> On 23 October 2012 12:34, Bence Kovács >> <[email protected]> wrote: >> >>> What is the advantage of using axis C in scarakins? >> >> Typically the C axis is the rotational axis that rotates about Z, so >> from a conventional naming point of view it makes some sense. >> The scarakins file is a bit strange, though, as that takes the unusual >> step of mapping Axis C to Joint 3. There is a general (and >> wrong/annoying) assumption in other parts of LinuxCNC that there is a >> 1:1 mapping from joints to axes. >> >>> I am new to LinuxCNC source, I am just investigating the code >>> structure. If you have idea where can be the problem, I can make >>> further investments. Don’t you think we should just modify scarakins >>> to use axis X Y Z A? >> >> I haven't looked at this in any detail, but it would possibly make >> more sense to leave scarakins as an XYZC kinematics, but to map axis C >> to joint 5. >> However I think that might leave us with spare axes in the display. >> >> -- >> atp >> If you can't fix it, you don't own it. >> http://www.ifixit.com/Manifesto >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_sfd2d_oct >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
