PN的启动过程

DCP

  • dcp是发现和基本配置协议的简称，实现在以太网链路层。通常处理profinet系统中网络地址和设备名称的管理。

    • Identify All
    • Identify
    • Set
    • Set > Flash
    • Set > Reset to Factory
    • Get
    • Hello

  • Identify All,识别全部（多播服务组）；可以快速查找所有连接的PN设备的设备名，IP地址，子网掩码，路由器地址，MAC地址，设备类型和供应商信息等信息列表，对应的应用案例如下图：

以上是step7的设置

以上是博图对应的设置

  • Identify,识别（多播服务）；每次PLC启动的时候会事先检查设备的名字和分配的名字是否对应的上，对应的上的就属于一个设备，对应不上的就会处于为组态的状态（LED闪烁），此时，可以手动为改设备分配设备名称。

以上是PLC启动时（此时设备名和IP都已经被分配完成）的DCP识别过程：
PLC（3e:6a）首先广播去问谁是某某站（名字） > DAP（9e:53）回复说我是某某站（名字），并附带了IP,子网，设备信息等等 > 匹配通过 > 完成启动过程检查
如果匹配不通过，则该站掉站，这个时候可以在组态工具上手动分配设备名给当前设备
如果设备名匹配通过，但是IP匹配不正确，这个时候PLC会直接把它组态里的IP分配给当前设备
如果设置了快速启动，这个时候就不用等待PLC来询问设备，而是设备主动发自己的设备名给PLC

  • SET，DCP设置。
 “设置”（单播服务）：

“设置”服务用于设置设备的名称或IP。它还具有其他一些特殊功能，例如将设备重置为出厂设置以及让设备LED闪烁，这些我们会在稍后提到。

在工程工具中，一个典型的初始设置PROFINET设备的方法是使用制造商提供的GSD文件对设备进行配置，然后离线设定参数和设备名称。在完成后，须使用工程工具中的命名功能将设备名称写入设备。您可阅读此处的设备命名约定  。工具用DCP“设置”命令来写入名称。

DCP“设置”可以是永久的或临时的。永久设置（保留，默认）的意思是名称永久存储在设备中（甚至在整个上电断电周期中）。暂时的意思是该名称在重新上电前使用，然后返回至默认值（例如：“”，无名称设置）。

在正常情况下，当控制器启动设备时，它会尝试使用DCP“识别”功能来通过其所配置的设备的名称查找该设备，然后控制器将检查PROFINET项目中由工程师设定的配置IP地址。如果IP地址没有设置或出现错误，控制器将使用DCP“设置”命令将IP地址写入设备（参见图1）。如果控制器发现不同的设备或节点已经拥有该IP地址，则控制器不能设置重复该地址。在此情况下，用户需在工程配置中或在冲突节点上更改设备的IP。IP可以设置为永久或临时的。如果IP被设置为临时的，在重新上电后，IP通常返回至零设置（0.0.0.0）；如果IP被设置为永久的，IP地址将被保留。
  • 重置
设置/重置为工厂设置“（单播服务）：

设置/重置为出厂设置“服务是一个特殊的设置命令，可在用户确认后将设备设置为PROFINET出厂（缺省）状态，名称为空名称（”“），IP设置为0.0.0.0。
  • 闪烁
闪烁’（单播服务）：
“设置闪烁’服务是另一个可选的特殊设置命令，可被用于通过设备上某处闪烁的LED来识别设备。如果存在多个与正在使用的设备类型相同的设备，则该服务可帮助用户更轻松地在视觉上识别设备。
  • 获取
 “获取”（单播服务）：

“获取”服务可用于从设备获取信息。例如，利用配置或诊断工具，用户可读出名称、IP地址和制造商信息。其他请求信息包括供应商ID、设备ID、设备类型、MAC地址和设备角色（如：控制器设备）等。
  • Hello
‘Hello’（多播服务）：

在设备上启用快速启动时，使用“Hello”服务。在使用该服务后，设备会在重新上电后会通知控制器（或多个控制器）它已重新上线，而不是等待控制器来找它，从而缩短启动时间。

ARP

  • 以下是ARP的报文

工作过程：
首先PLC（3e:6a）开始到处去问：谁是某某IP > 匹配上这个IP的站（9e:53）就回复了PLC某某IP在某某MAC对应的设备上
ARP其实是绑定了MAC和IP

DCP和ARP

  • 对于一个PLC的启动过程来说，应该是先有DCP，再有ARP，再是PN_CM(参数化阶段)，都完成了才到PN-RT。
  • 对于PN系统来说，MAC很重要，但相对于设备名称，其实IP没有那么重要：找不到设备名会掉站，但是再对应的设备名下找不到对应的IP时，PLC会直接分配一个新的IP（组态中的）给DAP站。
  • 我们知道MAC，去对应设备名时用的时DCP协议；我们去给设备分配IP时（把IP分配到DAP的ROM里）也是用的DCP协议；重新分配设备名也是用的DCP协议；重新分配IP用的也是DCP协议。
  • ARP在系统中：让PLC知道设备对应的IP和它的的MAC地址的绑定。

异常情况时的工作

  • 题外话：在H系统中同时存在R1和S2时，系统网络应该怎么接线？（S2设备全都串着走就行。）
    02C3A6E1-B450-4A59-AEA6-6401851644C8

  • 案例：用step7给IOD分配设备名，但是实际的设备和step7中的HSP设备类型是不一致的（比如实际是SP HA，而组态的HSP是SP），此时会出现什么情况？

    • 分配前的设备状态：
      分配前设备状态
    • 分配后的设备状态：
      分配后设备状态
    • 发现虽然实际和组态的设备类型不符合，但是设备名依旧可以分配（手动分配），但是IP并没有被改变！，下面从报文来分析这种情况：
    • 通过step7操作界面对设备分配名字时:
      • step7先发出"Set Req"
      • 设备回应"Set Ok"
      • step7继续确认设备是否叫这个设备名字"Ident Req"
      • 设备回应"Ident Ok",并且回复除设备名还包括Device_ID,IP等其他关键信息
      • step7把得到信息显示在操作界面上，会话没有再持续下去。
        dcp_分配名字时报文
    • 为什么IP没有被改变：抛开用step7操作界面手动分配IP的方式不谈，CPU一直在轮询没有被分配设备名的设备，此处如果实际设备和正常设备匹配，正常逻辑应是step7分配好设备名，设备把最新分配的设备名，加上自己带有的其他参数（ID,IP等）去回复CPU发出的确认请求，确认通过，CPU把存储在内存中的组态参数分配给设备，设备的IP被正确分配，整个过程依旧是DCP协议。不过通信的双方变成了CPU和设备之间：
      • 第一个图是H系统的master CPU发出的多播"Ident Req"
      • 第一个图是H系统的slave CPU发出的多播"Ident Req"
      • 两个图可以看出：在H-CPU中，CPU的master和slave都是独立在运行的！
        master_IOC多播询问IOD
        slave_IOC多播询问IOD
    • IOD回复给master CPU自己的参数信息"Ident Ok":
      在IOD和IOC之间，IOD持续回复IOC
    • CPU收到了IOD的确认后，并没有回复该IOD配置是错的，而是选择了忽略，其逻辑原因是：实际设备和组态中的设备不一致，CPU匹配不通过，如果回复IOD需要把CPU内存中的目标设备配置暴露出来，这是极不安全的行为，所以选择了忽略。

完整启动过程

  • 控制器发起DCP request:
    • 控制器先问设备名，如果存在拓扑信息时，控制器没收到Ident后会开始询问该设备花名（格式：邻居设备port.邻居设备名称）
  • 设备回应DCP Ident:
    • 回复时带的是自己的名字，如果控制器用花名问，设备就会回复自己花名名字。
    • IP，xid,ID等信息是给控制器的，控制器会去比对相关信息。
  • ARP过程：
    • 此时问设备IP，确认设备IP的MAC的关系
    • ARP在建立过程中的作用：虽然DCP会直接分配IP给设备，但是当系统中出现了另一个同样IP，同样设备类型，甚至同样设备名的另一个未组态设备时，就完全需要依靠ARP来判断，多个设备对控制器做了同样的ARP回应，会导致控制器认为这系列设备都是存在问题的而不会继续进行下一步，大家都将处于设备未组态状态以避免更多的问题发生。
  • PN_CM过程：
    • 该过程使用UDP/IP，作为连接过程中的参数化阶段而应用：
    • 控制器会对AR，CR,API，slot，subslot信息等等符合PN模型规范的字段结构发起请求并获得回复，最后完成参数化过程。
    • 重点：PN的模型化在此阶段进行，此阶段用到IP。如果IP冲突，或者没有IP，那么这些信息是不能够被获得的，IP的重要性在此处体现。
    • 详细过程：
      • PLC请求连接参数(AR,moduleID,submoduleID)，Device发回确认信息。（报文因实际情况，存在ModuleDiffBlock，不是所有CM都会有，diff并不意味着模块一定有报错或诊断，diff是否会最后对模块参数化造成影响取决于CPU对diff程度的判断）
      • PLC发起参数化写请求，会写DS(模块参数化DS长度)和IOdata（模块IO数据长度），device确认写入。
      • PLC发起写参数结束确认，device确认参数写结束
      • Device发起application ready，PLC确认。（如果不存在moduleDiffBlock，PN_CM在此时就结束了）：
      • 因为ModuleDiffBlock存在，PLC发起回答，设备确认：
  • 关于模型中的一些参数的说明：
    • 之前的理解有误，大多数设备API都是0，但是比如RFID它除了O之外也具有其他的API数值。不同的API它的模型结构是一致的，都符合同一个PN模型规范。一个设备具有0和其他的API，控制器用哪个API问， 设备就用哪个API的数据回，数据不同，但是都在PN模型的框架规范内。
  • 关于ModuleID,SubmoduleID,都是作为重要的模块参数表达模块类型，子模块类型。实际模块的ID和组态中的ID必须是匹配的，不同类型的模块，子模块ID可能是一致的，但是模块ID应是不同的，值由厂商定义：
    moduleID
posted @ 2024-12-06 17:34  你要去码头整点薯条吗  阅读(450)  评论(0)    收藏  举报