the tool coordinate system of a 6 DOF robot

Hello,yes, I have a G43 in my Gcode. I edit the tool table when set the tool in which the xyz is the position of the tip of tool and abc is just the tool's posture. and when first run a code, I use a command "M61 Q1"， which means the current tool is tool1 and read the parameters of this tool. It is correct when I don't change my tool posture(just run in a plane), when I run a gcode using A_ B_C_,it becomes wrong. The reason is parameters in tool table is just used to a offect, not used in forward and inverse kinematics computing of robot. When I run a gcode and want to change to posture, the reference point is also the sixth joint of robot,the position and posture is keeped correct, then the LInuxcnc use the xyzabc value of sixth joint minus the xyzabc values in tool table and let this new xyzabc become the tip of tool. It is wrong, I don't know if you really understand , but also thanks!!!!!!

Yes, I think so too, I think one way to handle this is to make the tool become a part of robot and let it becomes the sixth axis with previous sixth axis, but this way can't handle the radius compensation question; the other way is to change from 6-axis to 7-axis in genserkins, and make tool coordinate system become the seventh axis. Right? thanks!

Hello andypuch:
All joints of my robot are rotated joints, when I want to jog one of my joints to achieve a high precise. I found that the parameter of ENCREMENT in ini file, but the unit of that just inch, mm,when I set a value 1 deg or degree. It is wrong when I jog in AXIS interface. I am not sure that it is just the same when I use 1mm to substitute 1degree in jog mode.
thanks very much!!!

Thanks andypugh very much,I am so appreciated.
I found the question when I use the halscope and sample f-errored every 1ms. It is that when I attempt to make a rotated joint's degree become 0degree. I do that through jog before homing and then I just do nothing to let motor keep this degree. Then a following error occurs, in the file of halscope, I found that the degree was jitter dynastic, just had one time that lcec.0.0.Actual_Pos became 65536 which the period before this value was just closed to 0 and it is just the time the following error occurs. I don't know why does the actual position read form driver change so much at this time.
The halscope data is listed bellow. thanks again.

Yes, I also think this is funny too,drivers are made in myself country and it does not have great reputation. Encoders are absolute value with 17 bits and have 131072 pulse per tun. I am very surprised that it only has faults in zero position and the jitter value is 65536 and a half of 131072. Is there anything relationship with the two things?
BTW, is there anything wrong between lcec and pdo? It means that pdo value is just zero, but when read by lcec.ko ,this value changed to -65536?
Last, do you have some examples about the Ethercat and linuxcnc. I will check carefully for my configuration.
Thanks!!

Thanks very much, andypugh
I ask this question to my teacher, yes, just as you say, he found that the -65536 was zero too and there is something wrong with the type data of actual positon. And we have a test with another driver. we find that it has the same question in 0 position, then we changed the application program, and it is ok now!! The work now I should do is to find where the question is in Linuxcnc, from the data of halscope, I put my focus on lcec, because it is lcec to get the wrong data first.
Thanks again for all the help. I will tell you my results!!!