Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
2011/12/28 Rudy du Preez r...@asmsa.co.za It is in groups.yahoo.com under group SA-CNC-CLUB in photos. I tried searching Sorry, no matches were found for SA CNC CLUB Andrew -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
2011/12/28 Rudy du Preez r...@asmsa.co.za: In a recent posting I did say where photo's of my machine and an impeller cut with it can be looked at. It is in groups.yahoo.com under group SA-CNC-CLUB in photos. This is the discussion group for our local CNC club (South Africa), which I started about 2 years ago (SA-CNC-CLUB) and has about 40 members. Ok, You did mention the Yahoo group. AFAIK only group members can view posted pictures. But I was not able to check that for sure, because I did not find the group, see this link: http://groups.yahoo.com/search?query=sa-cnc-clubsort=relevance I have not been able to find a way to post photos to this forum. Yes, e-mail attachments are not encouraged, it is better to post pictures somewhere with a public access, like Google's Picasa. I guess that pastebin.com also accepts pictures. Lets focus a little on the process of going from world coordinates to joint coordinates. Starting from a toolpoint position in part or world coordinates xyz and unit tool vector ijk, these have to be transformed to joint coordinates XYZAC, with C the rotation angle of the top rotary table and A the rotation angle of the rotary table on which the top rotary table sits. The rotary axis of the A table is along the X-axis of the machine. X sits on Y which sits on Z (look at my pictures if necessary). Ok, I finally understood, how the joints are alligned in Your machine. The world coordinates I supply to EMC is the original xyz and the two angles A and C which have been computed in the CAM post-processor from ijk by: A = -arccos(k) and C = arctan2(i,j) Some adjustment of C is necessary to go beyond -180 deg and +180 deg. This is transformed by the inversekins: J0 = cos(C)*x - sin(C)*y j1 = sin(C)*cos(A)*x + cos(C)*cos(A)*y - sin(A)*z j2 = sin(C)*sin(A)*x + cos(C)*sin(A)*y + cos(A)*z j3 = A j4 = b (not used) j5 = C This is a working process for me so far as you can see from the photo of the impeller produced. Ok, I need You to expand on this in more details. Where are these formulas used? 1) In postprocessor of Your CAM program? 2) In Your custom kinematics module? 3) Somewhere else? If I use a G55 transformation of say G55 x10 y10, then EMC seems to add these values to x and y before it sends it to inversekins. The world coordinate origin is shifted to the new position. That seems fine. G55 is set by a G10 L2 P2 command. If I use a G55 of say G55 c45 nothing happens. It would have worked for me if EMC also added 45 to the value of C before it passes it on to inversekins. Practically I would only want to shift the C-axis when cutting parts like impellers with a number of blades. The GCODE for only one blade is the provided. Does EMC produce correct blade with the g-code for a single blade with trivkins module? If yes, can You check, if this approach is working (again - with trivkins module): 1) Save the blade's g-code in a separate file with the name o100.ngc; in that file define subroutine, just like the example You already provided: o100 sub G0 x25 y0 G1 x30 f200 G1 y5 G1 x25 G1 y0 o100 endsub 2) Create another file, which will call subroutines for each blade and rotate the top rotary table: a) place the tool in part's coordinate origin either by jogging or by a move in machine's coordinates, because I suspect that part's origin will be in the center of C joint and since You should know the location of C joint in machine coordinates, You can easily get there with (X,Y, Z numbers are random): G53 G0 X123 Y 123 Z123 A0 C0 b) zero G54 coordinates and select them: G10 L2 P1 x0 y0 z0 a0 c0 G54 G0 x0 y0 C0 c) call subroutine, produce the blade and rotate the C for 51.43: o100 call G0 X0 Y0 Z0 A0 C51.43 d) zero G54 again and do the next blade: G10 L2 P1 X0 Y0 Z0 A0 C0 o100 call e) I apologize beforehand for any mistakes in this code, as I myself actually have never used subroutines. I could also have passed on the ijk values as abc values to the inversekins. It would then have to work out the AC values, but there is quite a bit of checking and adjustment to C to be done. I am not sure if EMC could then pass on transformations. What is that You want to achieve with this? I feel pretty confident about my math skill and what I feel about Your formulas is that You are trying to implement things that I do not see that You need. You are adding the compensating moves along X, Y and Z so that tool stays at the same point of the part, when A or C joints are rotated. Actually that is very useful thing, because then parts that require complex 5-axis machining can be programmed a lot more easily, sometimes even by hand. Anyway, that would almost eliminate need for CAM postprocessor. That is very nice and extremely useful, but since You never mentioned that this is Your goal, I do not understand, why are You spending Your effort on this. Viesturs -- Write once.
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
On 28 Dec 2011, at 05:52, Rudy du Preez r...@asmsa.co.za wrote: If I use a G55 of say G55 c45 nothing happens. ... I hope the problem is now clearer and look forward to some response Yes, I now understand that you want to pass a tool XYZAC to the G code and have EMC2 convert the A and C to movements in joints 3 and 5. I am assuming that when you say g55 c45 that is a shorthand for g10 L2 C45 / g55? I am fairly sure that an axis word on the same line an a G55 is simply interpreted as a movement, and will be fast or slow dependent on whether G1 or G0 is active. I think the complication in your case is that you want to index explicitly in joint 5 not in World C to move from vane to vane, the G55 offset can only ever be in tool angle. I think that your vane-to-vane indexing will need to be an extra pin input into your kinematics routine. (or alternatively an offset component in the HAL between the position-command and the stepgen or pid. ) -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
I have found a way to do rotational shifts of the C-axis using XYZACkins. I use the B-axis for that and just program G0 Bxx at the start of each blade of the impeller, where xx is the absolute position of each blade; ie 0, 90, 180, 270 for 4 blades. The B position is available and free to use in the kinematics program. I use it and subtract it from the given C value coming from EMC in the inversekins and use the joint[4] value and add to the joint[5] value in the forwardkins. It may not be the most elegant way, but it works and I now only have to supply Gcode for one blade in a subroutine. I would not be able to have EMC do it beforehand with a G54 to G59 command, since I need the unshifted C-value from EMC as well as the shift value (in my case now B). The machine is now a 6-axis machine XYZABC with the B axis just used for rotational shifts of C! I suppose there are also other ways to do it such as using G43.1 instead of a B-axis. Thanks everybody for the discussions and help on this. It always amazes me how flexible EMC2 is. Marvelous! Rudy -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets (Andy Pugh)
2011/12/27 Rudy du Preez r...@asmsa.co.za:
I am confused with G54 to G59. Look at the following code and run it on a
simulation setup with Axis C rotation added:
G10 L2 P1 x0 y0 C0
G10 L2 P2 x10 y10 C0
G10 L2 P3 x0 y0 C-45
o100 sub
G0 x25 y0
G1 x30 f200
G1 y5
G1 x25
G1 y0
o100 endsub
g54 G0 x0 y0 C0
o100 call
g55 G0 x0 y0 C0
o100 call
g56 G0 x0 y0 C0
o100 call
G54 x0 y0 C0
m30
In trivial kinematics it does three squares, the first one in untransformed
coordinates, the second one with a shift of origin to x10 y10, and the 3rd
one with a rotational shift of -45 degrees. All seems as expected.
Good to hear. So do I understand that the issue is solved?
In world mode of a 4-axis system, with the inverse kinematics:
joints[0] = cos(C)*x - sin(C)*y; joints[1] = sin(C)*x + cos(C)*y
and forward kinematics:
x = cos(C)*joints[0] + sin(C)*joints[1]; y = -sin(C)*joints[0] +
cos[C]*joints[1]
it does the first and second squares in the same way as with trivialkins,
but the 3rd square is placed in the original world coordinate position, even
though the C-axis has been turned -45 degrees.
My question is: why does the G55 shift work the same but not the G56?
Short answer to Your last question - because You are screwing it up.
For a longer answer to Your question I would urge You to return to my
initial question - to disclose full information of what You did and
what results did You obtain. The same goes here:
1) from Your email I do not understand, if You have noticed, that it
is completely different kinematics module. And I am sure that You
definitely have not noticed that it's goal is to _simulate_ rotary
table.
2) You have not said, if You did load rotatekins with appropriate line
in Your HAL file - if the module is not loaded, You cannot expect it
to work :)
3) You copied out 2 lines of totally different kinematics module and
ignored everything else. So I would like You to take account _all_
lines that are in rotatekins forward and inverse kinematics:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/rotatekins.c
18 int kinematicsForward(const double *joints,
19 EmcPose * pos,
20 const KINEMATICS_FORWARD_FLAGS * fflags,
21 KINEMATICS_INVERSE_FLAGS * iflags)
22 {
23 double c_rad = -joints[5]*M_PI/180;
24 pos-tran.x = joints[0] * cos(c_rad) - joints[1] * sin(c_rad);
25 pos-tran.y = joints[0] * sin(c_rad) + joints[1] * cos(c_rad);
26 pos-tran.z = joints[2];
27 pos-a = joints[3];
28 pos-b = joints[4];
29 pos-c = joints[5];
30 pos-u = joints[6];
31 pos-v = joints[7];
32 pos-w = joints[8];
33
34 return 0;
35 }
36
37 int kinematicsInverse(const EmcPose * pos,
38 double *joints,
39 const KINEMATICS_INVERSE_FLAGS * iflags,
40 KINEMATICS_FORWARD_FLAGS * fflags)
41 {
42 double c_rad = pos-c*M_PI/180;
43 joints[0] = pos-tran.x * cos(c_rad) - pos-tran.y * sin(c_rad);
44 joints[1] = pos-tran.x * sin(c_rad) + pos-tran.y * cos(c_rad);
45 joints[2] = pos-tran.z;
46 joints[3] = pos-a;
47 joints[4] = pos-b;
48 joints[5] = pos-c;
49 joints[6] = pos-u;
50 joints[7] = pos-v;
51 joints[8] = pos-w;
52
53 return 0;
It is not very hard to notice, that in forward kinematics in c_rad
definition there is minussign before joint[5] value. And from
inverse kins we see that joints[5] = pos-c.
What does it all mean? It means that both rotations cancel each other
out and that is why You would not get any rotation. As the description
of that kinematics module says: Simple example kinematics for a
rotary table in software. It is not meant to be used with machines,
which do actually have rotary table.
So if I understand correctly, You already have a working solution with
trivkins. Is that correct?
Viesturs
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets (Viesturs)
Viesturs No I did not screw it up. My kinematics equations are an abstract from a full XYZACkins program with dx,dy,and dz axis offsets, which have been tested and has worked for a long time cutting impellers and other stuff. I wanted to keep it simple to address the issue of G54, to G59 offsets. What you did not notice are the signs of the sin(C) functions. It is a well known fact that sin(-C) = -sin(c) And cos(-C) = cos(C). I think my XYACkins is correct. It is the same as rotatekins when A, dx, dy and dz is zero. I want to be able to use offsets of C (and possibly A) while in world mode. Whereas it works OK in joint coordinates with trivkins, it seems to function differently in world mode using XYZCkins. My example code in the previous mail explained all that. Try the example code with rotatekins and trivkins and see what you get. Rudy -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets (Viesturs)
On 27 December 2011 18:38, Rudy du Preez r...@asmsa.co.za wrote: I want to be able to use offsets of C (and possibly A) while in world mode. Whereas it works OK in joint coordinates with trivkins, it seems to function differently in world mode using XYZCkins What does XYZCkins do that trivkins doesn't? Is it creating a virtual C-axis, or do you have a physical one? I assume by your statement that you see a rotation in your example in trivkins that you are talking about a physical C-axis? I am nowhere near my EMC2 machines until the 3rd, so this is conjecture but: I am fairly sure that coordinate system offsets are stored as an axis set, not a joint set. If you can run a non-trivial mechanism with cartesian offsets then that suggests that all the numbers inside the kins module are un-offset machine coordinates, and that G54 et al are added on post-kins. (and subtracted in the inverse kins). This may have a bearing on your assumptions. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets (Viesturs)
2011/12/27 Rudy du Preez r...@asmsa.co.za:
I want to be able to use offsets of C (and possibly A) while in world mode.
Whereas it works OK in joint coordinates with trivkins, it seems to function
differently in world mode using XYZCkins. My example code in the previous
mail explained all that.
Then I do not understand, what exactly is the problem.
You wrote that You have a 5 axis machine.
You have not explained, how the kinematics of the machine are designed
- are rotary joints tilting the tool or table etc.
You mentioned that everything is fine with trivkins, I explicitly
asked about it in my last email, but You did not answer.
Just like Andy, I do not understand, why exactly You do not want to
stay with trivkins. Where exactly is the problem?
BTW trivkins is using kinematics_identity which renders Your
statement that it works OK in joint coordinates with trivkins to be
false as there is no joint mode in trivkins:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/trivkins.c
67 KINEMATICS_TYPE kinematicsType()
68 {
69 return KINEMATICS_IDENTITY;
70 }
I am afraid that none of EMC users can give You detailed answer, if
You do not share Your details. Starting with Your machine (preferably
in pictures).
Viesturs
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
In a recent posting I did say where photo's of my machine and an impeller cut with it can be looked at. It is in groups.yahoo.com under group SA-CNC-CLUB in photos. This is the discussion group for our local CNC club (South Africa), which I started about 2 years ago (SA-CNC-CLUB) and has about 40 members. Most of the members are using EMC2 and we have converted probably more than 20 machines to EMC2 already. I personally have done 6. I have not been able to find a way to post photos to this forum. Lets focus a little on the process of going from world coordinates to joint coordinates. Starting from a toolpoint position in part or world coordinates xyz and unit tool vector ijk, these have to be transformed to joint coordinates XYZAC, with C the rotation angle of the top rotary table and A the rotation angle of the rotary table on which the top rotary table sits. The rotary axis of the A table is along the X-axis of the machine. X sits on Y which sits on Z (look at my pictures if necessary). The world coordinates I supply to EMC is the original xyz and the two angles A and C which have been computed in the CAM post-processor from ijk by: A = -arccos(k) and C = arctan2(i,j) Some adjustment of C is necessary to go beyond -180 deg and +180 deg. This is transformed by the inversekins: J0 = cos(C)*x - sin(C)*y j1 = sin(C)*cos(A)*x + cos(C)*cos(A)*y - sin(A)*z j2 = sin(C)*sin(A)*x + cos(C)*sin(A)*y + cos(A)*z j3 = A j4 = b (not used) j5 = C This is a working process for me so far as you can see from the photo of the impeller produced. If I use a G55 transformation of say G55 x10 y10, then EMC seems to add these values to x and y before it sends it to inversekins. The world coordinate origin is shifted to the new position. That seems fine. G55 is set by a G10 L2 P2 command. If I use a G55 of say G55 c45 nothing happens. It would have worked for me if EMC also added 45 to the value of C before it passes it on to inversekins. Practically I would only want to shift the C-axis when cutting parts like impellers with a number of blades. The GCODE for only one blade is the provided. I could also have passed on the ijk values as abc values to the inversekins. It would then have to work out the AC values, but there is quite a bit of checking and adjustment to C to be done. I am not sure if EMC could then pass on transformations. I hope the problem is now clearer and look forward to some response. Rudy -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
2011/12/26 rudy du preez rud...@iburst.co.za: I now have a working 5-axis table-table EMC2 controlled machine and have cut my first 7-bladed impeller (turbo-charger type with slanted and curved blades). However, I have to provide GCODE for all 7 blades since G54 type offsets do not seem to work for the C-axis, whereas they seem to work for x-, y- and z-axes (in WORLD mode). It would be nicer to index 51.43 deg around C-axis and then repeat the code for one blade 7 times. The C-axis is mounted on the A-axis which is mounted on the X, Y and Z axes in that order. Does anyone have an explanation for this behaviour? When I was working on the robot, I learned that G54 offset does work with A and C axes. I guess You need to share complete details, what You did to try and what exactly was the result You obtained. Do I understand correctly, that Your C axis is a rotary joint, mounted on XY table and rotating part around Z? If that is correct, is there any particular reason, why Your solution could not be: 1) create the g-code for one blade (without C movements); optional - save it as a subroutine file; 2) in another file - paste blade code or call subroutine, after that rotate C by 51.43 deg, do next blade by pasting code or calling the same subroutine again. Repeat until all blades are done. Note: calling subroutines will make the whole process easier to overview and understand. E.g. if You need some changes in blade's code, with subroutines You have to change only 1 place - subroutine file. Viesturs -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
Viesturs Thanks for the response. Perhaps before we go any deeper, have a look at what I have done. I Yahoogroups, under group SA-CNC-CLUB, you will find some photos of the 5-axis machine setup and the part cut. I tried to use a G54 in the GCODE for a C-axis offste - it did not seem to work. I will try again. Regards Rudy -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets
On 26 Dec 2011, at 15:06, Rudy du Preez r...@asmsa.co.za wrote: I tried to use a G54 in the GCODE for a C-axis offste - it did not seem to work. I will try again. As far as I know G54 only selects a coordinate system. If you want to put an offset into that (or any other) coordinate system you need to use G10. G92 is probably closer to what I think you want. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5-axis table-table kinematics: G54 offsets (Andy Pugh)
I am confused with G54 to G59. Look at the following code and run it on a simulation setup with Axis C rotation added: G10 L2 P1 x0 y0 C0 G10 L2 P2 x10 y10 C0 G10 L2 P3 x0 y0 C-45 o100 sub G0 x25 y0 G1 x30 f200 G1 y5 G1 x25 G1 y0 o100 endsub g54 G0 x0 y0 C0 o100 call g55 G0 x0 y0 C0 o100 call g56 G0 x0 y0 C0 o100 call G54 x0 y0 C0 m30 In trivial kinematics it does three squares, the first one in untransformed coordinates, the second one with a shift of origin to x10 y10, and the 3rd one with a rotational shift of -45 degrees. All seems as expected. In world mode of a 4-axis system, with the inverse kinematics: joints[0] = cos(C)*x - sin(C)*y; joints[1] = sin(C)*x + cos(C)*y and forward kinematics: x = cos(C)*joints[0] + sin(C)*joints[1]; y = -sin(C)*joints[0] + cos[C]*joints[1] it does the first and second squares in the same way as with trivialkins, but the 3rd square is placed in the original world coordinate position, even though the C-axis has been turned -45 degrees. My question is: why does the G55 shift work the same but not the G56? Rudy ** -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
