VEICHI SD700 EtherCAT — Er.960 on startup, clears after few F2 presses — why?

Start
Prev
1
Next
End

pushkarp
Offline
New Member

06 May 2026 06:42 #346198 by pushkarp

VEICHI SD700 EtherCAT — Er.960 on startup, clears after few F2 presses — why? was created by pushkarp

VEICHI SD700 EtherCAT — Er.960 on startup, clears after few F2 presses — why?Platform: LinuxCNC 2.9.8, Debian, kernel 6.12.57+deb13-rt-amd64 (PREEMPT_RT) Drive: VEICHI SD700 EtherCAT servo drive (firmware V1.2) Interface: linuxcnc-ethercat (lcec) with cia402 component Mode: CSP (Cyclic Synchronous Position), 1ms servo periodWhat's happeningEvery time I start LinuxCNC, the drive shows Er.960 (SYNC0 synchronous frame loss) for the first 15-30 seconds. During this time pressing F2 gives:

joint 0 amplifier fault
emc/task/taskintf.cc 976: Error on joint 0, command number 56

After pressing F2 several times over 15-30 seconds, the drive eventually shows "88" (operating state), I hear a click from the motor, and everything works fine after that — jogging, position feedback, motion programs all stable.My question is: why does Er.960 appear at startup and what is actually happening when F2 eventually causes it to go away?System latencyThis is likely relevant. My machine is an AMD Ryzen system on a Shenzhen Meigao generic motherboard. Latency-test shows:

Servo thread (1ms):  Max Jitter = 85,000 ns (85µs)
Base thread (25µs):  Max Jitter = 58,000 ns (58µs)

I have tried:

CPU governor set to performance
C-states disabled via cpupower
nomodeset (amdgpu blacklisted)
isolcpus, nohz_full, rcu_nocbs kernel parameters
idle=poll

None brought jitter below ~80µs — likely SMM interrupts from locked-down BIOS on this generic hardware.Current workaroundUsing

sync0Shift=500000

(500µs) in dcConf which helps the drive lock faster but doesn't eliminate the startup Er.960 completely.Config filessd700.xml

<?xml version="1.0"?>
<masters>
  <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

    <slave idx="0"
           type="generic"
           vid="00850104"
           pid="01030507"
           name="x"
           configPdos="true">

      <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="500000"/>

      <sdoConfig idx="6060" subIdx="00">
        <sdoDataRaw data="08"/>
      </sdoConfig>

      <syncManager idx="2" dir="out">
        <pdo idx="1601">
          <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="control-word"    halType="u32"/>
          <pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32"/>
          <pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
        </pdo>
      </syncManager>

      <syncManager idx="3" dir="in">
        <pdo idx="1A01">
          <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="status-word"           halType="u32"/>
          <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="position-actual-value" halType="s32"/>
          <pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velocity-actual-value" halType="s32"/>
        </pdo>
      </syncManager>

    </slave>
  </master>
</masters>

sd700.hal

loadusr -W lcec_conf sd700.xml
loadrt lcec
loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
loadrt cia402 count=1

addf lcec.read-all              servo-thread
addf cia402.0.read-all          servo-thread
addf motion-command-handler     servo-thread
addf motion-controller          servo-thread
addf cia402.0.write-all         servo-thread
addf lcec.write-all             servo-thread

net x-status-word   lcec.0.x.status-word           => cia402.0.statusword
net x-control-word  cia402.0.controlword            => lcec.0.x.control-word
net x-pos-raw       lcec.0.x.position-actual-value  => cia402.0.drv-actual-position
net x-tgt-raw       cia402.0.drv-target-position    => lcec.0.x.target-position
net x-pos-cmd       joint.0.motor-pos-cmd           => cia402.0.pos-cmd
net x-pos-fb        cia402.0.pos-fb                 => joint.0.motor-pos-fb
net x-enable        joint.0.amp-enable-out          => cia402.0.enable
net x-fault         cia402.0.drv-fault              => joint.0.amp-fault-in

setp cia402.0.pos-scale 10000
setp iocontrol.0.emc-enable-in 1
net tool-prep  iocontrol.0.tool-prepare  => iocontrol.0.tool-prepared
net tool-chg   iocontrol.0.tool-change   => iocontrol.0.tool-changed

sd700.ini

[EMC]
MACHINE = sd700-test
VERSION = 1.1

[DISPLAY]
DISPLAY    = axis
CYCLE_TIME = 0.100

[TASK]
TASK       = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = linuxcnc.var

[EMCMOT]
EMCMOT       = motmod
COMM_TIMEOUT = 1.0
SERVO_PERIOD = 1000000

[HAL]
HALFILE = sd700.hal

[KINS]
KINEMATICS = trivkins coordinates=X
JOINTS     = 1

[TRAJ]
COORDINATES             = X
LINEAR_UNITS            = mm
ANGULAR_UNITS           = degree
MAX_LINEAR_VELOCITY     = 5
MAX_LINEAR_ACCELERATION = 20

[EMCIO]
EMCIO      = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

[AXIS_X]
MAX_VELOCITY     = 5
MAX_ACCELERATION = 20
MIN_LIMIT        = -9999
MAX_LIMIT        =  9999

[JOINT_0]
TYPE             = LINEAR
HOME             = 0.0
MAX_VELOCITY     = 5
MAX_ACCELERATION = 20
MIN_LIMIT        = -9999
MAX_LIMIT        =  9999
FERROR           = 50
MIN_FERROR       = 5
SCALE            = 10000
HOME_SEARCH_VEL  = 0
HOME_LATCH_VEL   = 0
HOME_SEQUENCE    = 0

Specific questions

Is Er.960 at startup expected behavior on a high-jitter system while DC sync is being acquired, or does it indicate a configuration problem?
Why does pressing F2 (which sends CIA402 enable controlword) help the drive clear Er.960 and lock onto DC sync? I would not expect an application-layer command to affect DC sync acquisition.
Is there a way to make the drive more tolerant of sync frame jitter during the initial lock-in period — either via SDO parameters or lcec config?
Would increasing
```
refClockSyncCycles
```
help, and what is the recommended value for a high-jitter system?
Is there a known-good
```
sync0Shift
```
formula based on measured max jitter? (e.g. shift = 2x max jitter?)

Any insight appreciated. The system works well once locked — just trying to understand the startup behavior and ideally make it more reliable.

Please Log in or Create an account to join the conversation.

Start
Prev
1
Next
End

Time to create page: 0.098 seconds