the choices of NIC for 6 DOF robot with linuxcnc

One more addition.

Are you sure your hardware is fast enough for the cycle period you use?

Does the PLL error disappear if you use only one or only two slaves?

Thanks sirop, the communication cycle is 2ms which I read from the Twincat.
When I just use only one slave, it is also has the PLL error.
Also another question is I don't know how to set the tool coordinate system. When is robot is ready and the reference point is at the wrist of robot, not at the position of tool's origin point.
I am very sorry to disturb you.
Thanks again.

chuchengbing wrote:

Thanks sirop, the communication cycle is 2ms which I read from the Twincat.
When I just use only one slave, it is also has the PLL error.
Also another question is I don't know how to set the tool coordinate system. When is robot is ready and the reference point is at the wrist of robot, not at the position of tool's origin point.
I am very sorry to disturb you.
Thanks again.

Maybe, you should worry less about the PLL error as it happens at the very end when you exit linuxcnc.
Do you stop and maybe delete the thread of your Etherlab master component before?

Anyway...
These errors should be investigated:

[ 25.363120] EtherCAT ERROR 0-5: Reception of CoE upload response failed: No response.
[ 25.363122] EtherCAT ERROR 0-5: Failed to read mapped PDO entry.
[ 25.363124] EtherCAT ERROR 0-5: Failed to read mapped PDO entries for PDO 0x1A00.

So you do some "exchange" between CNC and EtherCAT.
As for CNC (coordinate systems, G Code): there are more experienced people on this forum for these subjects.

Hello sirop:
BTW, what is 3.4.9-rtai-686-pse? I thought there is only 3.4.9-rtai-686-pae in the LinixCNC world.[/quote]
I am sorry that the system is 3.4.9-rtai-686-pae and it is a misspell.
3. Your slave seems to support 64 bit timestamps? But your master runs on 32 bit?
Mixing 32 and 64 bit timestamps can also be a problem.
See this example:
lists.etherlab.org/pipermail/etherlab-users/2012/001693.html
Yes, you are right, the system is really on 32 bit and the DC is 64 bit too. When I run the command of ethercat salve -v in the terminal, it shows: Distributed clocks: yes, 64 bit.
Now are there any methods to make the DC run on 32 bit or should I change my system to run on 64 bit?
Thank you

chuchengbing wrote:

3. Your slave seems to support 64 bit timestamps? But your master runs on 32 bit?
Mixing 32 and 64 bit timestamps can also be a problem.
See this example:
lists.etherlab.org/pipermail/etherlab-users/2012/001693.html
Yes, you are right, the system is really on 32 bit and the DC is 64 bit too. When I run the command of ethercat salve -v in the terminal, it shows: Distributed clocks: yes, 64 bit.
Now are there any methods to make the DC run on 32 bit or should I change my system to run on 64 bit?
Thank you

Check and maybe correct on your slaves registers 0x0008 ( Bit 3, Distributed Clocks (width)), 0x0981 (Bit 4, Extension of Start Time Cyclic Operation). See download.beckhoff.com/download/document/...c2_registers_2i7.pdf .

If this does not help, switch to 64 bit master.

Hello sirop, sorry for disturbing you again.
I have tried to change our master from 32 bit to 64 bit and had questions in installing LinuxCNC on 64 bit system.The ESC in my ethercat slave devices is beckhoff's ET1100. I just refer to some documents in the web, it seems that EK1100 and EL1××× also use EK1100 as ESC incide and they also have a good performance running on the 32 bit master.
The PLL question is becoming so severe that it occurs when LinuxCNC is running, not just dropping out the LinuxCNC and the result of that is the servo driver change its state from OP state to SAFEOP state.
Now,I really doubt if changing the master from 32 bit to 64 bit could handle this question. Do you have any other advice? Thank you very much!!!!!!!!!

chuchengbing wrote:

Now,I really doubt if changing the master from 32 bit to 64 bit could handle this question. Do you have any other advice? Thank you very much!!!!!!!!!

You guess you have posted a similar question to lists.etherlab.org/pipermail/etherlab-dev/2016/000545.html .

First check the admissible cycle times for position profile and Cyclic Synchronous Position (or CSP) .
If that is not the problem, then try the middle way: Interpolated position mode which is less jitter sensitive.

You can actually do much more debugging by writing your own master component
and/or probing the SYNC0 siganls with a scope if that is posssible on your slaves.

Checking the manual of the slaves I use, I find also this advice:

For example, in a system with a cycle time of 1ms and +/-100 microseconds of timing jitter on the
master, the master could be configured to transmit it's process data with a 500 microsecond offset (half
the cycle time) from the SYNC0 time on the slaves. This would ensure that the slave devices received
the process data well clear of the SYNC0 update. Since the slaves are configured in SYNC0
synchronization mode, they will not use the updated process data until the SYNC0 signal occurs.

Hi expert, sirop:
Yes, it is really my post in the EtherLAB, you are so wise and always pay much attention to posts listed in forms. All through I have heard mang times, I don't understand the real mean of jitters and it is the CPU jitter or master jitter. there is little documents depicting this. Do you have some details about this or have some documents about it ?　
Thanks a lot ..

chuchengbing wrote:

Hi expert, sirop:
Yes, it is really my post in the EtherLAB, you are so wise and always pay much attention to posts listed in forms. All through I have heard mang times, I don't understand the real mean of jitters and it is the CPU jitter or master jitter. there is little documents depicting this. Do you have some details about this or have some documents about it ?　
Thanks a lot ..

Jitter is a deviation from ideal cyclic time. There are docs on, for instance,
download.beckhoff.com/download/document/...1_technology_2i2.pdf
Chapter 9 Distributed Clocks

Besides CPU/OS jitter the NIC of the master may add some deviation as well as the slaves.
So, yes this theme is not trivial.