the choices of NIC for 6 DOF robot with linuxcnc

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.