the tool coordinate system of a 6 DOF robot

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

I am not exactly sure what question you are asking, but I think that angular jogs are interpreted as mm.
You can modify the increments list:
linuxcnc.org/docs/2.7/html/config/ini-co...tml#_display_section

I don't know if that would help you.

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.

chuchengbing wrote: 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.

That's interesting. That rather sounds like the encoder counter is not handling encoder-wrap correctly.

Can you remind me what hardware you are using? What are the encoders? How many counts-per-turn?

It is also possible that 65536 was meant to be zero, but one bit of the data was held high. But this is only a possibility with parallel hardware (which includes PCI but not PCIe)

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