DND论坛 你的意见 设为首页 加入收藏 联系远方

系统主菜单

新闻更新

CAN&CANopen

DeviceNet

开发笔记

DND论坛 

本站留言 

网络链接

精彩文集

关于DND

热点文章点击

黑客故事之第八军团 2003-12-28[20173] 

简单的DeviceNet开发实验网络搭建(一) 2004-01-04[12953] 

CAN总线浪涌保护的简单方法 2005-06-06[10662] 

關於新增sunny為版主的公告 2009-02-20[8970] 

DeviceNet—开发者指南(远方译自CIA) 2004-01-04[7905] 

最新回复文章

DeviceNet中的对象概念 2003-12-29[5162] 

DeviceNet—开发者指南(远方译自CIA) 2004-01-04[7905] 

简单的DeviceNet开发实验网络搭建(一) 2004-01-04[12953] 

Producer/Consumer网络通讯模型 2004-01-04[4144] 

关于CAN物理层协议的探讨(远方译) 2005-03-16[7666] 

路,在脚下延伸……我坚定而执着地走着!

你的位置:DND首页 > DeviceNet > 阅读文章


 

Producer/Consumer网络通讯模型

时间:2004-01-04 阅读4145次

 

 

1.显性报文和I/O报文(Explicit and I/O messaging)

   工厂自动化网络要传送一般的计算机通讯网络中需传送的报文,同时需要传送实时的输入/输出(I/O)控制信息及整个控制系统中各控制器互锁信息等。我们用显性报文和I/O报文来分别表示。

显性报文
   用来上载和下载程序,修改设备组态,记载数据日志,作趋势分析和诊断等功能,例如我们可以用显性报文对控制器中的五个定时器重写默认值或执行自测试操作。它们的结构十分灵活,数据域中带有通讯网络所采用的协议信息和要求操作服务的指令。每个节点(设备)必须解释每个显性报文,操作所请求的任务,并生成响应。为按通讯协议解释这种显性报文,在真正要用到的数据上必须有较大一块的附加量(overhead)。这种类型的报文在数据量的大小和使用频率上都是非常不确定的。

I/O报文
   在本质上是隐性的(Implicit),因而有时也称为隐性报文,它的数据域中常不包括协议信息,仅仅是实时的I/O控制数据,这些数据的含义是预定义的。因而在节点中对处理这些数据所需的时间大大减小,I/O报文的一个例子是控制器将输出数据发送给一个I/O块设备(I/O Block),然后 I/O块按照它的输入数据响应给控制器。为解释这种类型的报文而必须引入的附加量(overhead)小,数据短,使用频率一致,并且需要高的性能:对I/O报文传送的可靠性,送达时间的确定性及可重复性有很高的要求。
过去,用于I/O控制的网络不能处理发送显性报文时在发送数据的时间及报文尺寸上的不定性因素。控制设备提供商不得不使用不同的网络来管理这两种不同报文类型的不同要求。 Rockwell Automation/AB公司的Data Highway/Remote I/O网络和西门子的 Profibus FMS/ProfibusDP网络就是这种情况的表现。

吞吐量(throughput)
   是来自设备的输入数据传送到需要它的所有节点和节点产生的输出数据(根据用户的逻辑程序产生)传送到需要它的所有节点的速率。节点可以是传感器、人机界面(Human-Machine Interfaces-HMI)、控制器、 数据记录仪、警报监视器、起动器、变频驱动器等。吞吐量由波特率、协议效率和网络模型决定。下面我们简要讨论一下这些因素。

波特率(Band Rate)
   是把数字信号放到网上去的原始速率,通常用每秒比特位或字节表示,人们最常用波特率来衡量网络的性能。实际上这是个误解,对于现在新的网络,它是影响吞吐量的三个因素中最不重要的一个。

协议效率(protocol efficiency)
   定义为数据包中有效数据位与整个包长度的比值。一般是用百分比表示,它是通讯协议中附加量的量度。虽然重要,但不如数据传送和交换的方法(网络模型)重要,如果某个特定的信息交换需要2个或多个数据包来完成,跟只需1个数据包相比,如果一个网络比另一个网络的协议效率高25%就没有任何意义了。

网络模型(Network Model)
   现今的工业自动化网络中有两种主要的网络模型,即源/目的地模型(Source/Destination)和生产者/消费者 (Producer/Customer)模型。典型的源/目的地模型的一个数据包如下所示:

源地址 目的地址

数据

循环冗余检验码


   在主/从系统中经常用这种模型,主/从是一个层次体系,系统中包含一个发起所有通讯的主机,从机只能跟主机通讯并且以“只答”的方式(speak only when spoken to), 当用于I/O信息时,这种网络就只能限于这种功能。

   点对点结构优于主/从结构,提供更多的灵活性,在点对点的系统中,设备既可以发起通讯,也可以响应系统中其它设备的请求。由于所要求的灵活性,支持点对点的网络使用显性报文进行通讯。

   为保证各节点设备都可有机会送信号到网络,大多数点对点的网络使用某种类型的令牌传递算法,并且经过多年的改善,算法使得节点对总线的访问更加公平,但正是点对点网络的灵活性使得控制器之间的互锁问题更加复杂化,响应的时间随着网络的负载、需传送信息的节点与当前令牌持有者之间的“距离”有很大的不定性。

   不论是主/从结构,还是点对点通讯结构。基于源/目的地的网络在把同样数据发往不同节点时都消耗了过多带宽,另外要实现协同控制,象以同步的方式将一个设定值同时送达不同的驱动器将更加困难,因为数据到达每个驱动器(目的地)的时间是不同的。ControlNet中采用了一个全新的生产者/消费者网络模型。一个典型的生产者/消费者模型的数据包结构如下:

标识符 数据 循环冗余检验码


在生产者/消费者模型中,信息按内容来标识,如果一个节点要接收一个数据,仅仅需识别与此信息相连的特定的标识符,每个数据包不再需要源地址位和目标地址位。

因为数据是按内容进行标识的,数据源只需将数据发送一次。许多需用此数据的节点通过在网上同时识别这个标识符,可同时地从同一生产者取用此消费同一数据。消费者节点之间可实现精确的同步,而且提高了带宽的有效使用率,其它的设备加入网络后并不增加网络负载,因为它们同样可以消费这些相同的信息,当节点时,对发送多个数据组时,对每个数据组使用不同的标识符。图是一个使用生产者/消费者模型的示例。
 


生产者/消费者模型

报文#1 来自传感器I/O的参考位置信息可多点传送给控制器1,控制器2和人机界面设备。
报文#2 速度指令可多点传送给所有三个驱动器和人机界面设备。
源/目的地模型实现多点的同时传送是很困难的,在使用该模型时实现同样操作(假设单向报文传送)需要7个报文。


2. I/O触发机制

   除了传统的轮询方法(polling)外,生产者/消费者模型还允许用两种新的功能强大的I/O触发方法:状态改变发送(Change-Of-State)和周期I/O发送(Cyclic)。轮询是从源/目的地模型产生的,它本质上是一种两个报文的双向处理(发送方输出数据命令,接收节点收到后作出响应并把反应送回),往往用在主机到它的从机之间,许多轮询周期充满了相同的输入和输出数据,这些冗余的数据浪费了大量网络带宽。

   在采用状态改变(基于事件)触发机制的系统中,仅当数据改变时节点发送数据,并同时地发送给所有需要该数据的节点没有轮询周期带来的延迟。同时一个作为背景的心跳(heart beat)信息可以周期地发送,消费者可用它来辨别设备是状态没有改变还是设备不在线(离线),采用状态改变触发机制可以显著的降低网络阻塞和负载,特别当设备需要重复的接收、处理和生成同一种数据时。另外,一般情况下发送4个心跳信息后再发送1个真正数据。

   周期性发送(基于时间)时,数据可根据用户选择的速度来产生,数据的更新速度与节点和应用相匹配。例如在优化的PID控制中,传感器的信息可以以精确的间隔进行采样,或者控制器可以收集大块数据后以每秒若干次且大于操作员接口的反应速度进行发送。这样,可为快速变化的I/O信息的节点保留了带宽。

市场上两个模型的现场总线例子如下:

源/目的地模型

   -Ethernet
   -Interbus S
   -Modbus Plus
   -AS-I
   -Remote I/O
   -Date Highway Plus
   -Profibus(FMS, DP, PA等)

生产者/消费者模型

   -ControlNet
   -DeviceNet
   -Foundation Fieldbus

 

 

 

 fanxl617 

 [00038] 

发表于2010-09-15 13:01 

 

你好,我是一名研究生,现在开始做devicenet产品,但是我只有一块devicenet协议芯片DN1022,和它配套的说明书,只有流出的串口说明。主站以后可以有一个带devicenet主站模块的plc。有一个版本的devicenet协议
请问远方大哥,我用这些资料能够开发一个group2 only从站不?我想请问如果我用这些资源开始从站开发,应该如何着手呢?

 

 

姓 名:   密 码: 注册 修改

 

论坛最新贴子

ODVA核心成员













Copyright © 2003 DnDev.com  All Rights Reserved.
DND-DeviceNet 开发网  版权所有

制作维护:远方   Email:yuanfangjy@163.com