PN IO应用层
发展
-
以前，SIMATIC模块要提供一些特定的信息的方法是将特定信息保存到
SSL里，通过查询的方法获得。- SSL中文名叫做
系统状态列表，帮助里面有些时候有写成SZL，不过都是一样的东西。 - 在Step7中使用
SFC51(RDSYSST)，SFB54(RALRM)来获取SSL和报告系统错误，具体的records数据结构会根据你的SSL ID在博图帮助里索引出来
部分SSL ID如图：
- SSL中文名叫做
-
在Step7中如果要获得数据记录和诊断记录，依旧可以通过SFB52(RDREC)和SFB53(WRREC)获得，因为早期PLC没有硬件标识符的概念，所以SFB的ID管脚填写IO组件的实际逻辑地址，
如果是输出模块，第15位必须设置为1；如果是混合模块，则以地址数值更小的为准。
PN-IO的设备模型
- slot:插槽，和硬件组态里面的插槽概念一致，一般来说slot1是PLC,IM那些（slot0一般是ps，MP系统最大插槽号31）
- subslot：位于物理的slot中，是个虚拟的概念。比如混合模块Input和Output位于不同的两个subslots；又比如带有MSO/MSI(最多分4个subslot)和Submodule功能的IO模块，他们可以根据需求和组态配置分出多个subslot出来。
- Channel: 最小级别，也是实际承载数据的级别，它的理解就是正常里面里面的通道概念。
应用关系AR和应用程序进程标识符API
- AR:控制器或者监管者必须通过AR终端才能链接到AR设备，举个具体的例子，
AR指的就是数据交互的传输管道（pn网络，DP所承载的数据管道等） - CR:符合PN规定的每一个AR中必须至少满足以下三个通信关系（CR）：分别是
records data（异步）,alarm data（中断）,I/O data（循环或同步刷新_IRT）。除它们三个外，其余的CR是可选项。 - API:
应用程序进程标识符。可以理解为一个PN IO系统里面的逻辑设备。API0（默认的）是PN指定的设备（API地址范围是0x00000000和0x00010000-0x0001FFFF），其他的是供应商指定的设备,或者认为是行规，在文章的最后会具体解释API的含义。
.如上，还有一些地址段的API表示DP，一些地址段表示编码器，一些表示，LO-Link设备等等很多很多地址段来分类很多很多设备类型
用户结构标识符USI
- USI：
用户结构标识符。用于标识以下设备（第15位=1的都表示子插槽级别，就是16#8000开头的USI）- （在诊断记录中）通道诊断，W#16#8000
- （在诊断记录中）拓展通道诊断, W#16#8002
- （在诊断记录中）供应商特定的通道诊断, W#16#000-W#16#7FFF
- （在组态记录中）用于请求目标组态，W#16#8000
- （在组态记录中）用于请求实际组态，W#16#8001
- 上面的例子都是16#80xx开头的，表示子插槽级别，结构内容最小到通道
- 16#C0xx开头的是插槽级别的，结构内容最小到Slot下面的子插槽
- 16#F0xx开头的是API级别的
- 16#E0xx开头的是AR级别的
- 不同的寻址级别的差别是定义具体寻址结构的时候所带信息量的多少，16#80xx能够带的信息最多最丰富
- USI可以认为等同于用户程序（RDREC/WRREC）请求数据的寻址index号但是又不完全等同，比如诊断用的800A/E00C这类index号就属于叠加了基础USI=16#8000/16#8002的结果，但你不能直接用USI=16#8000去寻址诊断，因为USI=16#8000是寻址组态记录的index号。
组态和诊断记录的结构及含义
- 头结构(组态和诊断记录具有相同的header结构)：
Blocktype:- 用W#16#0001和W#16#0002分别表示中断传输通道1和2（中断类）
- 用W#16#0010表示诊断记录（诊断类）
- 用W#16#0012,W#16#0013,W#16#8104分别表示目标，实际，目标实际比较（组态类）
BlockLength:- 块长度包含了请求来的结构的长度信息，但是不包括BlockType和BlockLength本身（共4字节），意味着我们计算
总长度=(BlockLength值 + 4)bytes。
- 块长度包含了请求来的结构的长度信息，但是不包括BlockType和BlockLength本身（共4字节），意味着我们计算
BlockVersion:- Version本身由高字节版本（01）和低字节版本（01或者00）两个字节构成
- 对于W#16#0100的版本，它所表现的内容更少，它没有承载关于API的信息；
- 对于W#16#0101的版本，它所表现的内容更多，它承载了关于API的信息；
组态记录集结构
- 16#80xx级别，组态USI(这里和用户程序的
index号对应)的最后一位只有0和1，其中0表示请求的是目标组态，1表示请求的是实际组态。
.由图，其实如果
USI=E#16#E002的话，是可以得到实际和目标组态的差异信息的。这个索引号特殊一点。
- 组态记录的结构（USI为16#xx01和xx00结构一致）
如上介绍，组态记录的包括了BlockType,BlockLength,BlockVersion三个word。我们直接接着header的结构往下介绍：
- 当BlocVersion=W#16#0100时（不带API信息），整体结构就该为header+numberodslots+根据slotsnumber迭代的slots结构+根据slots结构里面的subslotsnumber迭代而来的subslots结构。如图：
.因为NumberOfSlots=2,所以调用了2遍Rec_Slot_000_001结构
.因为第一个Slots里面NumberOfSubSlots=2，所以第一个Slots下面跟了2个SubSlots,同理，第二个Slots下面只跟了一个Subslots
.计算总长度：header(6bytes)+numberofslots(2bytes)+slots1(8bytes)+subslots1/2(6bytes+6bytes)+slots2(8bytes)+subslots1(6bytes)=42bytes;
.BlockLength显示值应该是：42-4=38bytes。
- 当BlocVersion=W#16#0101时（带API信息），整体结构会在上述基础上迭代一个NumberOfAPIs的个数。如图：
请自行体会和上述0100版本的差异，注意各个number的值。
- 当USI=W#16#E002时（特殊情况）
.也请自行体会结构和上面两种结构的差异，除了number外，还需注意看命名的差异。
-
ModuleState的含义：
-
SubmoduleState的含义用bit表达，详情查找帮助
诊断记录集
-
诊断USI的类型比较多。例如上面提到的
W#16#8000（通道诊断）和W#16#8002（扩展通道诊断），这俩是反馈回来的基础USI，不属于用户寻址的index就属于标准化USI值的范围，除此之外还有0A,0B,0C,10,11,12,13（属于用户最终使用的index）等一系列标准化USI。剩下的一些则是供应商定制的结构。 -
0A,0B,0C,10,11,12,13的区别：他们
在数据结构上没有什么太多区别。
-
A,B,C,10,11,12,13在具体信息量和触发条件上有一点细微的区别（前提不变，若第一位是8则为子插槽级，C为模块级，E为AR级，F为API级）：
- xx0A，10，11：诊断通道数据和扩展通道数据（由反馈的USI？=8000/8002确定）
- xx0B，12，113: 在上述基础增加供应商特定的数据
- xx0C: 在xx0B基础上可能多包含IE/PB连接器状态信息
-
诊断结构
- header:
- 判断BlockVersion，等于0100时如下：
- 判断BlockVersion，等于0101时如下（依旧只多API信息）：
- 根据给出的USI结构中的值判断下挂的诊断结构，当USI=8000时：
- 当USI=8002时：
- 当USI=0-16#7FFF时：
- 迭代次数由发生
诊断的模块和模块里面的通道数决定。 - ChannelErrorType:表示故障类型，不完全举例如下：
- ChannelNumber:如果值等于
W#16#8000则为子模块，其他值都属于供应商特定或保留内容。 - ChannelPropertes:每一位拆分表达了不同的含义，所传递的信息比较多，详情查找帮助。
- header:
-
应用案例说明
如图，一共两个子模块故障，一个子模块上两个通道故障，一个子模块上一个通道故障，用E00C(AR层级去请求)，迭代结构如下：
.我们平时由RALRM得到的error_code其实本质就是在这里给出的。
.用E（AR级）去请求是因为发生了跨插槽的多种故障，如果用8(channel级)则只会得到一个插槽的内容，当然一个插槽可以有多个通道诊断。
其他记录号
以下均是和用户程序index号直接对应的记录号（DS number）
- 返回I&M标识和维护数据
I&M数据的结构
- I&M0：
- I&M1:
- I&M2:
- I&M3：
- I&M4:
更新：API的具体含义
-
API等于0和不等于0的情况：
- 当API为0时，表示的是这个设备遵循Profinet标准的对象模型->即API=0表示当前设备遵从从Slot到Subslot的寻址方式。
- 当API不等于0的时候，表示当前设备又加上了一些新的定义内容，这个内容是行规定义或者供应商定义。
不必遵守Slot，Subslot的寻址方式，依旧遵守PN模型规范。 - 一个符合Profinet标准的设备一定是一个API（等于0）+API（不等于0）（非必须）的结构汇总，这个设备在做符合Profinet标准通信的时候一定是基于API=0的结构的！！
- 之前的理解有误，虽然大多数设备API都是0，但是比如RFID，它除了O之外也具有其他的API数值。不同的API它的模型结构是一致的，都符合同一个PN模型规范。一个设备具有0和其他的API，控制器用哪个API问， 设备就用哪个API的数据回，数据不同，但是都在PN模型的框架规范内。
-
API的层级关系：
-
API具体含义，详情参见profibus.com
更新：关于组态数据记录
图中是通过Connect（是建立时IOC和IOD之间自动定义的）的方式实现的，所以看不到index号（E000/E001/E002），但是用的结构都是E000/E001的结构。如果用Read就可以看到index号了（用rdrec/wrrec）
此处看到API=0，寻址方式时遵守PN的对象模型的/写的时候API会变成16#ffff,不过不影响结构。
这里看出在PN-CM的时候PLC就把组态信息自动分配给各个IOD了。用的就是E000/E001，关于组态记录的实际应用案例就从这里反应出来。
PN IO 模型层级关系
图中，0x8000的subslot,0x8001的subslot都是抽象出来的模型。实际上的接口设备需要和这个模型对应起来。
图中，0x8000和0x9000的区别是R1的冗余系统和S1/S2的系统的接口模型区别。
注意：subslot1,subslot0x8000,subslot0x8001等等，都是实实在在从同一个SLOT中分出来的，实际上存在的层级模型
举例：比如一个系统中，SLOT1是整个接口模块，subslot1是接口模块物理地址，subslot8000是接口模块的映射地址（和subslot1有同样的订货号），subslot8001/8002是BA（接口适配器）的订货号。所有的subslot都对应submodule，他们都具备submoduleIdentNumber和I&Mdata等概念。
和插槽概念对应的模块层级模型
在PN设备的建立连接过程中，会去比较HSP/Gsdml中的这些信息和实际设备中的这些信息的一致性。
比较ModuleIdentNumber/subModuleIdentNumber等等这些信息才能最终确认一个模块是不是实际插入的模块，换句话说，如果ModuleIdentNumber/subModuleIdentNumber匹配但是订货号不匹配，设备可能会报错但是能运行，反之，设备可能压根旧不会被识别.
-
Assert Data （assert data和PN的数据结构/模型结构上没有什么关系，只是记录在此处）:
- 对于PA类的产品，carrier module/terminal block这些物理模块有Assert Data。
- Assert Data的读取是通过寻址slot上的module读取来的，换句话：如果当前slot是空的，则一般情况下读不到当前对应的assert data。
- 侧面说明，Assert data数据属于模块的附加数据。，换言之：不能直接像寻址插槽一样寻址到它，它只能通过上面的模块间接被寻址到。
- 因为不被包含在模型中，carrier module/terminal block没有I&M数据。他们不具备谈论I&M data的基础。（不是PN系统中的模块分类，I&M是PN系统module才有的结构）。
- server module占用一个slot，它相当于一个module，数据能够直接被获取，它具有I&M数据。
-
device name 在IM模块中的优先级：
- 在sp ha中，更换IM或者bus adapter（BA）时具有以下情况：
- 旧IM更换全新的BA模块，最终接口节点的设备名以旧IM中为准。
- 全新的IM更换到旧的BA模块，最终接口节点设备名以旧的BA中为准。
- 旧IM更换旧BA模块，最终接口节点的设备名以旧BA模块中的为准。
- 说明：新的模块没有预设设备名，是空。在接口组件中，若IM和BA都同时存储设备名，BA具有更高的设备名优先级。这个功能的实际作用是方便设备的快速更换。
- SP家族不同于SP HA家族，因其存在BA模块不能拆卸的情况，某些情况下Server Module也会参与到设备名的分配中(意味server module也会存储im设备的设备名，目的是方便设备的快速更换)。
- 在sp ha中，更换IM或者bus adapter（BA）时具有以下情况：
浙公网安备 33010602011771号