IO-Link技术规范
V1.1.3与V1.1.4
逐条对比分析（2）
前言
话说上篇文章一经发布，便收获了许多技术大佬们的青睐，我们公众号的关注量也是快速上涨，小编在此感谢大家的认可与期待。
书接上文，本篇将继续为大家逐条分析v1.1.4更新的内容，还请各位童鞋前排入座！！！
具体对比分析
温馨提示：由于引用两版规范的原文较多，后续排版默认将v1.1.3内容放置于前，v1.1.4内容放置于后，方便各位童鞋直观对比。
1
版本/ID对比的状态机
v1.1.3版本
v1.1.4版本细化了对版本的比较，以及对DeviceID的比较，影响不是很大。
2
从站SM状态机
v1.1.3版本
v1.1.4版本状态机增加了一个T14 通讯速率的变化的事件，这个事件是指在标识检查阶段，SM模块要求请求切换速率。
这种情况极为罕见，虽然规范在review中说明了其背景来源，是主站在兼容模式切换中可能的场景，但仔细推断应用场景，小编暂时没有想到合适的场景，如果后续要切换通信速率，为啥不一开始就切换呢？因此小编认为这个T14的增加只是增加了完备性，并不影响实际的使用。
3
PM状态
这里更多是歧义的解释，比如v1.1.3版本有ParamBreak、StoreRequest等误导性名称，v1.1.4统一做了更改。
同时在状态Download_2和Upload_3的ISDU ErrorType 0x8022 做了进一步的澄清。
v1.1.3版本
v1.1.4版本
另外v1.1.4版本增加了系统重启时的事件，状态回到Idle_0，并解锁本地参数的访问，如果同时在下载参数，则丢弃下载的参数。
4
DS模块
v1.1.4版本进一步澄清在DSLock状态或者DSIdle状态，对未处理的DS_Command拒绝，并返回0x8023/0x8036的命令，对现有模式无影响。
v1.1.3版本
v1.1.4版本
v1.1.4版本还对哪些需要DS_DELETE进行了明确：包括修改CVID、CDID以及PortMode的改变和Validation的改变。（除了bakeup&restor与Restore之间的变化之外）
5
重启命令
v1.1.4版本要求从站在接收到主站的重启命令后，至少等待3个MasterCycle再进行重启，即要求对主站的ISDU请求完成确认再进行重启。
v1.1.3版本
v1.1.4版本
6
SMI_MasterIdentification
v1.1.4版本增加了一句话：要求同一个MasterID和VendorID的设备，在功能和性能上应该是一致的。
7
SMI_ParServToDS
v1.1.4版本明确，如果不支持DS或者在端口未激活，则该API应该返回一个Result（-）INCONSISTENT_DS_DATA。即增加了一个SMI的错误类型（0x4036）。
8
SMI_ParamWriteBatch
v1.1.4版本修改了ExpArgBlockID，从0xFFF0修改为0x7001。
v1.1.3版本
v1.1.4版本
9
CM 状态机
T3事件：PortStatusInfo的状态从PREOPERATE改为了NOT_AVAILBLE。
v1.1.3版本
v1.1.4版本
T8事件：增加了详细的说明。
v1.1.3版本
v1.1.4版本
T9/10/11事件：删除诊断信息明确了只删除从站上报的信息，端口的不删除。
v1.1.3版本
v1.1.4版本
T12~T15事件：做了详细说明。
v1.1.3版本
v1.1.4版本
结语
由于篇幅原因，剩余部分内容我们将在下期全量放送，还请各位童鞋稍作等候。当然也可直接后台私信我们，第一时间获取全部资料，IO-Link小睿随时恭候大家
<<< END >>>
微信号丨Rasight
官方网站丨www.rasight.cn