2、同步对象(SYNC)基础：SYNC对象定义、生产者与消费者模型、同步周期配置

好，咱们开始聊SYNC。说实话，在CANopen的众多对象里，SYNC是我个人觉得最「优雅」的一个。它不传输复杂数据，不参与设备配置，它的任务就一个——告诉大家「时间到了，该干活了」。

你想想看，在一个多轴运动控制系统里，六个伺服电机要同时执行位置指令。如果每个电机各自为政，有的早到0.1毫秒，有的晚到0.1毫秒，那整个系统就乱套了。SYNC就是那个「发令枪」。

2.1 SYNC对象定义

SYNC对象在CANopen标准里，对应的COB-ID是0x80。嗯，就这一个ID，没有扩展帧的烦恼。它的数据域通常为0字节，或者最多带1个字节的计数器。

为什么数据域可以是空的？因为SYNC的本质就是一个「事件信号」。它不需要告诉你任何具体数值，只需要在总线上出现，大家就知道该同步了。

我在项目中遇到过有人试图修改SYNC的COB-ID，想把它改成0x180。结果呢？整个网络的同步机制全乱了，因为其他节点根本不认这个ID。记住，SYNC的COB-ID是硬编码的，别去动它。

2.2 生产者与消费者模型

SYNC的通信模型非常简单，就是经典的一对多模式。

生产者：通常只有一个，一般是运动控制器或主站。它负责按照配置好的周期，定时往总线上发送SYNC报文。

消费者：可以有多个，所有需要同步的从站设备都是消费者。它们监听总线上的SYNC报文，收到后立即执行预定的动作。

说白了，这就是一个「广播」机制。生产者喊一声「开始」，所有消费者同时响应。

我曾经调试过一个印刷机项目，三个伺服轴需要精确同步。一开始我让每个轴各自用内部定时器触发，结果总差那么几毫秒。后来换成SYNC同步，所有轴在同一个时钟节拍下工作，问题迎刃而解。

2.3 同步周期配置

同步周期，就是两次SYNC报文之间的时间间隔。这个值由生产者决定，消费者只能被动接受。

配置同步周期，主要涉及两个对象字典条目：

索引	名称	说明
0x1005	SYNC COB-ID	定义SYNC的标识符，通常固定为0x80
0x1006	通信循环周期	以微秒为单位，0表示禁止SYNC
0x1007	同步窗口长度	消费者接收SYNC的有效时间窗口

举个例子，如果你把0x1006设为10000（微秒），那就是10ms发一次SYNC。这个值怎么选？

• 运动控制：通常1ms~10ms，要求高实时性
• IO采集：10ms~100ms，够用就行
• 传感器数据：100ms~1s，看采样率需求

我曾经犯过一个错：在一个液压伺服系统里，把同步周期设成了500微秒。结果总线负载直接飙到80%，丢帧严重。后来改成2ms，系统稳定了，控制精度也没下降多少。所以，周期不是越短越好，够用就行。

2.4 同步计数器

有些应用场景下，光靠SYNC还不够。比如，你希望每收到3次SYNC才执行一次动作。这时候就需要同步计数器了。

SYNC报文可以带1个字节的计数器，范围0~255。每次发送SYNC时，计数器加1。消费者可以配置成「每收到N次SYNC才触发一次」。这个N值通常存储在对象字典的某个自定义索引里。

为什么需要这个？我举个例子：在一个包装机械里，主控制器每10ms发一次SYNC，但切刀只需要每50ms动作一次。通过配置计数器为5，切刀控制器每收到5次SYNC才执行一次切割。这样既保持了同步性，又降低了执行频率。

2.5 实战配置示例

假设你用的是CANopenNode，配置一个SYNC生产者大概是这样：

// 在对象字典中配置SYNC
// 0x1005: SYNC COB-ID，固定为0x80
OD_write(0x1005, 0x00, 0x80);

// 0x1006: 通信循环周期，设为10ms
OD_write(0x1006, 0x00, 10000);  // 单位：微秒

// 启动SYNC生产者
syncProducerStart();

消费者这边，只需要监听0x80的报文，收到后触发PDO发送即可。在CANopenNode里，这个逻辑是自动处理的，你只需要在对象字典里把PDO的传输类型设为「同步」模式。

好了，SYNC的基础就这些。说白了，它就是一根「指挥棒」，让所有设备在同一个节拍下工作。下一章我们会聊SYNC的高级用法，包括如何用它来触发PDO、如何做时间戳同步。到时候你会发现，这根「指挥棒」能玩出的花样还挺多。