智能化I/O（共9篇）
智能化I/O 篇1
2012年11月6日~10日, 第14届“中国国际工业博览会” (简称“工博会”) 于上海新国际博览中心隆重举办。在工博会的几个展项中, “工业自动化展”无疑是历次工博会的重头戏, 无论规模还是人气都首屈一指。作为工业自动化领域的重量级企业之一, 研华科技自然不会缺席该项展会。本届工博会上, 研华以“智能自动化, 无缝隙整合”为主题盛装亮相, 全面展示了研华在物联网、工厂自动化、设备自动化等领域的最新产品及解决方案。
在研华丰富的产品线中, 工业自动化产品具有不可或缺的重要地位。作为I/O类产品的一员, 其ADAM系列数据采集模块更以其独特的外观设计和优异的性能而广受欢迎。研华I/O产品的发展也一直是工业自动化业内人士的关注重点。本届工博会期间, 本刊记者有幸采访了研华科技两位工业自动化I/O领域的专家———研华 (中国) 工业自动化事业群产品业务经理张守廷先生及研华工业自动化事业群产品经理陈维庭先生, 就I/O产品领域相关问题作了深入交流。
2012年, 受国际国内经济环境的影响, 工控领域企业都或多或少地受到冲击。张守廷先生表示, 今年研华业绩也受到了国际经济环境的影响。工业自动化业务在出口设备和光伏领域受到一定冲击, 然而在军工、电力及科研领域, 销售业绩出现了显著增长。所以, 整体市场增长情况符合预期。张先生表示, 之所以能够较好地化解不良国际经济环境所带来的冲击, 要归因于研华多年的经营中建立了良好的市场应对机制, 针对市场风云变幻, 能够及时而迅速地做出调整, 制定应对策略, 从而从容化解危机。
研华的I/O产品主要分为两个类别:一类是数据采集 (DAQ) 等板卡产品;另一类就是远程I/O模块。对于板卡类产品, 研华今年的发展重点并不仅在于硬件升级, 而是重点进行了驱动软件的升级。张守廷先生介绍到, 这主要是研华针对用户群的发展而作出的调整。随着产品应用范围越来越广, 用户也由过去主要集中于计算机领域扩展到各行各业。在这样的情形下, 如何能够最大程度地提高产品的易用度, 使用户能够在采用研华产品的过程中付出最小的时间成本, 成为研华的重点努力方向。张先生介绍到, 今年对板卡类产品所做的驱动升级, 能够大大减少客户的二次开发时间, 使产品能够更快速地应用于用户的具体行业需求。
谈及远程I/O产品的发展, 陈维庭先生则重点阐释了研华本次工博会的主题“智能自动化, 无缝隙整合”。陈先生介绍到, 目前远程I/O领域呈现的一个重要发展趋势就是不同界面、不同总线的整合。随着技术的不断发展, 用户的应用环境和应用需求也日趋复杂, 如何实现各种不同界面、不同接口的无缝隙融合, 成为摆在工业自动化厂商面前的重要课题。面对这样的发展趋势, 研华富有远见地提出了“智能自动化, 无缝隙整合”的发展方略, 清晰地阐明了研华在工业自动化领域的发展方向。
此外, 陈维庭先生还介绍了研华两款远程I/O的新品:ADAM-2000系列无线数据采集模块及ADAM-6600系列产品。ADAM-2000系列无线数据采集模块是研华科技专门针对物联网及无线传感器网络应用而设计的产品。该产品集成了温度、湿度、光照及CO2测量功能, 并针对物联网应用需求特别进行了低功耗设计, 采用普通电池供电, 工作时间可达一年以上, 并具备低电报警功能。该产品特别适合诸如环境监测、交通运输、矿山等应用领域。ADAM-6600系列产品则是研华针对客户对智能化远程I/O产品需求而设计的新产品。该系列产品为用户提供基于IEC-61499标准的可编程控制功能, 相比于目前广泛采用的IEC-61131标准, IEC-61499标准特别针对分布式控制应用而设计, 采用基于IEC-61499标准的控制模块, 可以简化系统架构, 实现更加高效率和智能化的功能。
通过与两位专家的交流, 笔者感受到, 在工控领域硬件产品日趋同质化的今天, 单纯的某款硬件产品已经无法成为市场中克敌制胜的法宝, 而服务的优劣及良好的客户体验将成为竞争差异化的关键所在。在这方面, 研华无疑又一次走在了前列。期待研华能够早日为用户带来其所诠释的自动化理念———“智能自动化, 无缝隙整合”。
智能化I/O 篇2
Python提供了必要的函数和方法进行默认情况下的文件基本操作。你可以用file对象做大部分的文件操作。
open函数
你必须先用Python内置的open()函数打开一个文件，创建一个file对象，相关的辅助方法才可以调用它进行读写。
语法：
file bject = open(file_name [, access_mode][, buffering])
各个参数的细节如下：
file_name：file_name变量是一个包含了你要访问的文件名称的字符串值。
access_mode：access_mode决定了打开文件的模式：只读，写入，追加等。所有可取值见如下的完全列表。这个参数是非强制的，默认文件访问模式为只读(r)。
buffering:如果buffering的值被设为0，就不会有寄存。如果buffering的值取1，访问文件时会寄存行。如果将buffering的值设为大于1的整数，表明了这就是的寄存区的缓冲大小。如果取负值，寄存区的缓冲大小则为系统默认。
不同模式打开文件的完全列表：
智能化I/O 篇3
电机温度是电机运行的一项重要参数, 主要包括电机定子温度和电机轴承温度。传统测量电机温度的方法主要有两种, 即采用PLC热电阻模块测量和采用温度变送器测量, 这两种方法均不同程度地存在一些缺点。
智能以太网I/O服务器采用先进的设计理念, 可将多种形式的输入信号转换为以太网信号上传, 以太网信号传输介质支持双绞线和光纤。信号输入类型包括DI、AI、AO、热电偶、热电阻等。智能以太网I/O服务器同时可执行输出DO、AO等输出信号。Jet I/O 6512 服务器是一款热电阻输入服务器, 支持两线、三线、四线制的接线方式, 对温度的测量范围较宽, 可分段满足被测对象的温度监测要求。
1 采用PLC热电阻模块测温法
采用PLC热电阻测温模块测量一个温度变量的系统结构见图1。该方法的优点是系统简单, 将每个被测量的pt100热电阻通过电缆接至PLC热电阻模块即可测量。但该法存在以下缺点:
(1) 热电阻输入的PLC模块价格较贵, 一个常用的6通道RTD测温模块价格约10 000元;
(2) 为提高测量精度, 每个pt100热电阻需要3芯电缆。以1台电机为例, 正常需测量8个温度量 (6个定子温度, 2个轴承温度) , 如果设备距离较远, 且测量电机较多, 则用电缆敷设不经济。表1为采用热电阻PLC模块测量电机温度参数的主要元器件价格。
2 采用温度变送器测量
采用开关量输出的温度变送器测量一个温度变量的系统结构如图2所示。温度变送器将被测量的pt100热电阻参数转换为模拟量输出或数字量输出。如果变送器采用模拟量输出, 其输出信号再接入PLC的模拟量输入模块, 则系统繁琐, 可直接采用第一种方法;如果温度变送器采用数字量输出, 由表2所示的主要元器件和价格统计情况可知, 选用此种方法有一定的经济优势, 但得不到连续的温度量。电缆用量也没有减少。
3 采用智能以太网I/O服务器测量电机温度
忻州神达能源集团原平选煤化工有限公司500万t选煤厂采用了智能以太网I/O服务器测量电机温度变量, 系统结构示意如图3。采用该技术可把热电阻智能以太网服务器设置在被测电机附近, 减少由热电阻至测温模块之间的长度, 然后通过光纤上传至集控室。表3为采用智能以太网服务器测量电机温度所需主要元器件和价格。在涡北选煤厂等新建选煤厂中, 测量电机温度也采用此种方法。
4 结 论
从三种电机温度测量方法的对比可知, 所测电机数量越多、电机越集中, 采用智能以太网I/O服务器的经济优势和性能优势越明显。另外从控制电缆的用量来看, 前两种方案的控制电缆长度是从电机至控制柜的距离, 采用第三种方案所用的电缆长度为从电机至附近控制箱距离, 控制箱至上级系统仅通过光纤或双绞线连接。由此可见, 控制电缆量会显著减少, 节省了大量电缆的采购和敷设费用。
在有些控制系统比较完善的选煤厂中, 各类测量控制装置也需用到以太网光纤作为通讯介质。本系统和其他系统可共用传输介质和路由器等设备, 从而可将不同控制系统合并, 达到简化选煤厂整体控制系统结构、节省成本的目的。
综上所述, 智能以太网I/O服务器在测量电机温度方面有一定技术优势, 随着产品性能不断提升以及产品价格的逐渐降低, 该方法在选煤厂的应用前景广阔。
参考文献
[1]王廷尧.以太网技术与应用[M].北京:人民邮电出版社, 2005.
[2]徐国林.PLC应用技术[M].北京:机械工业出版社, 2007.
[3]商海峰.基于工业以太网与现场总线的选煤厂综合自动化系统的设计[J].煤炭加工与综合利用, 2010 (6) :25-28.
[4]杨渊, 宗世棠.工业智能以太网I/O服务器在选煤厂的应用[J].煤炭加工与综合利用, 2011 (6) :34-36.
[5]成举炳.选煤厂低压电气数据采集系统[J].煤炭加工与综合利用, 2012 (2) :30-31.
8086的I／O写周期 篇4
8086在执行输出指令时进入I／0写周期，在I／O写周期中将指定寄存器的内容输出到指定的I／O端口，图2．1l是I／O写周期的时序图。I／O写周期和存储器写周期基本相同，
区别在于两点，一是M／在I／O写周期内为低电平，表示当前进行的是I／0操作；二是I／0端口的地址只有16位，因此图2．11中T1、T2期间没有出现A19～A16。
关于I/O模拟的讨论 篇5
多年以来,Windows都为这种机制而引以为豪,其实在Windows下,有这样的一个原则,硬件例如CPU最好是一直工作的,这样才能得到更加充分的利用,而在Windows下,程序都是以进程形式获得在CPU这类的硬件中执行的机会,而作为轻量级的进程,执行资源的实际获得者线程的角度上看,就是要让线程不要停下来,需要让各个线程就它们正在执行的操作进行相互的通信,Microsoft在这个领域进行了数十年的研究和测试,终于开发了这种机制,叫做I/O完成端口(I/O completion port),通过这种机制,就可以让线程在读取设备或写入设备的时候不必挂起等待设备的响应,从而很大程度上提高了吞吐量,实现了计算机性能的巨大提升,如图1所示。
首先分析一下Windows的消息机制,只有了解了Windows的消息机制才能明白,什么是消息,Windows下利用上述的I/O机制,实现了线程与I/O之间的交互不必需要线程的挂起,但是消息产生到接收又是怎么解决的呢?Windows感知到有I/O的操作以后,会将该消息进行封装成为struct tagMSG(详细内容请查阅MSDN),这个结构体中将包含消息的类型,参数,时间,位置,和传递的对象。Windows将该消息投入到Windows消息队列,然后等待应用程序从队列中提取相对应的消息,在这里要明确几个问题,便是模拟I/O的层次问题和模拟的关键是什么?正如图1表达的,模拟可以在驱动级,系统级,或者用户级3个级别上进行,关键就在于模拟的何种消息、何时、何位置、发送给那些应用程序,这就成为了I/O模拟的关键所在。
2 用户级I/O模拟
正如图1所示,从消息队列到指定应用程序的这一段路径上的I/O模拟,便是用户级模拟,用户级模拟的特点是:
(1)通过Windows消息机制,并由系统发出,给指定的应用程序。
(2)指定的应用程序通过自己的窗口句柄等标识,从消息队列中获取消息。
这一部分的模拟需要用到Windows API,首先了解到在Windows下的应用程序,都会拥有一个自己的窗口句柄,这如同一个ID一样,指向了某一个窗口程序,就通过获取到指定应用程序的句柄,然后发送特定消息,这如何来实现呢,分享一段模拟代码:
这里就不再赘述一些细节了,但是需要注意的是,在FindWindowsEx中的第二参数,解决一些存在父子窗口的情况,通过对子窗口的句柄,有点类似线程ID了,就可以向指定线程发送消息,按键的消息需要延迟200毫秒,这是因为正常人的点击操作便是200毫秒,这样首先可以避免写入消息队列过快,造成溢出,也可以满足一些需要一定按键时长程序的特殊要求。这里的PostMessage函数有时可以用SendMessage函数替代,本身参数上没有区别,但是核心在于如果使用的是PostMessage那么发出消息后,模拟程序是不会理会该消息的处理的,但是使用SendMessage的话,应用程序就会一直等待该消息被正确处理的反馈,这样会一定程度上影响模拟程序的正常运行,因此建议使用PostMessage函数。其次Windows的消息叫做Windows_Message,这类消息共有1024(0x0400),所以可以设置高于1024的自定义消息。这样就可以模拟很多Windows下无法模拟的I/O消息,但是弊端就是要为自定义消息编写处理函数。
3 系统级I/O模拟
这一部分分析操作系统到消息队列这一段路径上的I/O模拟,这一段的模拟所具有的特点是:
(1)系统并不指定发送的对象,接受消息的进程为当前的活动进程。
(2)接收消息的程序可以发生改变,换句话说是可以存在进程间切换的。
首先分析一下正常情况下键盘消息的产生过程,这好比要完成对某一好友的问候,那么应当先选中一个好友,然后对他发送你好的消息,这一过程就是平时使用鼠标点击选中当前活动进程,或是用键盘切换选择活动进程的过程。这一部分的模拟通过Windows API也是可以实现的,下面我们分享一段模拟代码:
键盘消息的模拟,需要讨论的是虚键码MapVirtualKey函数,这个函数把逻辑上的‘U’键转换成计算机可以识别的二进制虚键码,可以不使用这个函数,但是效果就是模拟出的键盘消息不会被一些DirectX类游戏所接受,鼠标事件的模拟就要显得相对复杂了,因为不仅要产生事件消息,还要产生位置消息,这里的案例是对640*480窗口向全屏的鼠标坐标转换,有点类似窗口压缩的意思,需要解释的是对于一些DirectX类的射击游戏的鼠标模拟,这套方案并不是首选方案,其原因会在下面的驱动级模拟中详细给大家分析。
4 驱动级I/O模拟
这一部分要分析从驱动到操作系统和一种特殊的消息传递方式,在这之前,先要了解这样一个事实,在应用程序中有一类游戏应用程序叫做DirectX类游戏,比如冰封王座,CS,街霸,铁拳等,这类游戏的一个共同特征是:
(1)需要很高的即时操作要求,而且操作频繁。
(2)不使用Windows的消息机制,而是与驱动直接交互。
首先为了很好的人机交互感,这类游戏都会将操作精确到毫秒级,而且会产生大量的操作,这就要求对I/O缓存的一定使用要求,其次为了实现这类游戏的即时要求,这类游戏都会选择绕过Windows消息机制,因为通过Windows消息机制至少都有数百毫秒的延时,这难以满足游戏的需要,为此目的,这类游戏会选择直接与驱动进行交互,来接受I/O的操作。在这个层面的模拟就会显得比较复杂,而且Windows的API就不太好用了。
因此在这个层面的I/O模拟有两种设计方案,一种是需要重写某些I/O设备的驱动,这是比较麻烦的,还有一种方法是将消息写入某个特定的驱动然后产生相应的消息,下面着重分享一下第二种方法,写入驱动程序:
使用写入驱动的接口是WinI/O提供的,通过WinI/O就可以和驱动进行一定程度上的交互,分析一下这几段关键性代码:首先KBCWait4IBE()函数是用来检测驱动的缓存是否为空的,因为开始讨论到,如果模拟的消息过平凡地投递到驱动,那么消息就会出现一定程度上的溢出,这样的话,很多的操作就会出现丢失,这样是很不好的,所以每当要将内容写入到驱动的时候,都要检测一下是否驱动的缓存已经满了,这并不会造成严重的延迟,但是对一些组合操作来讲,丢失一个操作就有可能丢失了一批操作,所以在驱动级模拟I/O的操作关键就在于避免缓存溢出。此外,MY_KEY_DOWN&MY_KEY_UP是相类似的,将差异分析一下,首先,要产生的按键的ASCII码转换为虚键码,然后等待缓存,当可以写入的时候首先要发送一个命令消息0xD2,即为写入缓存,然后得到写入的权限后写入一个数据0xE2,告诉驱动要写入的是一个键盘消息,然后等待缓存,写入要写入消息的虚键码,于是消息被写入,但是这个时候键盘消息是按下消息,如何将其按起呢?使用0x80也就是标识当前某一按键被取消的标识位,当这一位被标识后,按键消息就变成了按键取消消息,从而从键盘上驱动模拟发出这一消息。
5 结语
详细介绍了在用户级、系统级和驱动级实现对I/O设备的模拟操作,分享了Windows API编程、WinIO驱动编程的案例。也详细地分析了Windows消息机制的优缺之处和如何利用和脱离Windows消息机制。
摘要：详细分析Windows的I/O机制,提出了分别在用户级、系统级、驱动级的I/O模拟操作,通过实际案例和源代码分享在I/O模拟上的得失,着重介绍鼠标与键盘的模拟。
关键词：I/O机制,I/O模拟
参考文献
对象I/O技术的模拟实现 篇6
我们知道C++对象是“存活”在RAM中的，由于RAM的易失性[1]，程序需要将对象存入磁盘中，将来需要时再把对象读入内存加以恢复，这样一来就好像对象一直“活”着一样，因此对象的持久化是C++中的一个非常重要的操作。
许多程序员可能有这样的误区，利用下面的代码：saveClassName();className=readClassName();p=new className;不就轻松实现对象的保存和恢复了吗?
需要指出的是，在C++中，是通过new A而非new“A”（或className=“A”,new className）实例化A的对象。换句话说，试图利用下面的代码className=readClassName（）;p=new className；来达到通过类的字符串名称动态创建对象的做法是根本行不通的，因为p=new className根本无法通过编译！[2]
由此我们得出对象的持久化需要的两个条件：
(1)获取对象所属类的名称的能力；
(2)能根据类的字符串名字动态创建对象的能力。
这两种能力的获得目前有两种解决方案：
一是由C++编译器（compiler）提供———例如Borland C++4.5:
二是由程序员自己加上去。
本文是通过第二种方法模拟实现对象的持久化机制，从而深入探讨了对象I/O技术的实现机制。
本文结构如下，首先描述了对象持久化的实现，其次对实现进行了验证，最后是论文进行总结。
1 对象持久化的实现
为了说明问题而又不失一般性，我们假定有三个类，分别是Object,A和B，其中A和B都派生于Object，类的定义如下：
为了让对象具备持久化的两个条件，需要依次为对象添加如下信息。
1.1 为每个类增加对象创建函数CreatObject，如表2所示。
1.2 增加类的识别信息（类名称或ID等）以及继承信息，由于这部分信息比较多，可以将其整合到一个结构体Struct ClassInfo中。ClassInfo中保存有两个链表：
类的继承链表和程序中所有类的类型信息链表。类的识别能力就由这两个链表来完成。换句话说，我们希望在main函数执行之前内存中就存在如图1所示的两个链表。其中类的继承链表是由Struct ClassInfo的带参构造函数完成的（在VC++中，结构体也可以有构造函数），而类的类型信息链表则是由ClassInfoInit类完成的。Struct ClassInfo和ClassInfoInit的定义如表3所示。注意，链表的创建是在它们的构造函数中完成的。
最后一步，将类型信息作为类的静态的成员变量添加进来，并为每个类实例化静态的初始化类，目的是在main函数执行之前得到图1所示的两个链表。
在这要强调一下static关键字的作用：
(1)如果类的成员变量被Static关键字所修饰，则这该属性不是为类中的每个对象分别拥有，而是共用，其引用形式不是对象成员变量，而是类成员变量，即不需要市里实例化对象就可以使用。成员函数也与此相仿[3]。
(2)如果对象（包括作为类成员的对象），如initObject、ObjectInfo等，被说明为Static，则这些对象是在main函数执行之前就已经存在了，换句话说，这些对象的构造函数是在main函数调用之前就已经被调用了。因此在main函数执行之前，内存中就已经存在着图1所示的链表就可以理解了。
我们添加的RTTI信息能否有效的支持对象的持久化可以由试验来验证。
2 试验
该试验主要验证了对象持久化必须具备的两个能力，即动态创建对象能力和获取对象所属类的能力。试验的环境如下：操作系统Windows XP sp2,IDE环境是VC++6.0 SP6。如需要全部源代码可与作者联系（hehh6@henu.edu.cn）。
通过对象增加的RTTI信息（增加的静态成员变量），获取对象所属类的能力自然具备。
动态创建对象能力实际上就是根据类的字符串名称来实例化对象的能力，在图1所示链表的支持下，该功能可以非常轻松的实现。
思路如下：通过ClassInfo：:pFirstClass查找类名匹配的ClassInfo，利用ClassInfo中的pCreateObject指针实例化对象,为方便起见,可为程序增加查找函数
3 结束语
本文在手动添加的RTTI信息的支持下实现了对象的持久化，从中读者可以深入了解对象持久化的的实现机制。
在商业的编译器VC++中其实现持久化是通过一个神秘的宏，当将该宏展开后，VC++实现持久化的的思路和本文大同小异，只是更精巧[4]。
参考文献
[1]Stanley B.Lippman.Inside The C++Object Model(深度探索C++对象模型)[M].侯捷,译.武汉:华中科技大学出版社,2001.
[2]葛磊.The Object's Permanence Technology and Its Realization in MFC[J].开封大学学报,2006,20(1).
[3]钱能.C++程序设计教程[M].第二版.北京:清华大学出版社,2005:418-419.
远程I/O系统在罐区的应用 篇7
关键词：远程I/O,通信,DCS
0 引言
金陵石化芳烃部中间罐区仪表采用远程RTU接入DCS方式, 现场检测、报警仪表的信号接入远程I/O单元, 由远程I/O单元转换成通信信号, 连接至相应的DCS系统, 控制仪表及可燃气有毒气检测仪表采用电缆直连至相应的DCS系统。
现场每套远程I/O系统输出两路Modbus信号, 分别进入两个不同装置的DCS系统, 一路进PX装置, 另一路进3重整装置。
1 远程I/O系统
模块化的远程I/O系统通过总线接口将现场二进制和模拟量的传感器和执行器连接至控制系统, 传输安全区域或者爆炸危险区域的现场过程数据。远程I/O系统可连接设备:流量变送器、阀门定位器、压力传感器或者温度变送器、热电偶 (TCs) 、电阻式温度检测器 (RTDs) 、机械触点以及声光报警器等。远程I/O系统兼容Profibus-DP、Modbus-RTU、Modbus TCP/IP和Foundation Fieldbus等网络协议。远程I/O适用于爆炸危险区或者严酷工业环境, 例如海洋平台和户外。典型的应用行业包括石油天然气 (内陆及海洋) 、制药、化工、污水处理、食品饮料等。
远程I/O系统具备高适应性和操作简单的特征。系统安装在现场设备侧, 仅需一根总线电缆即可连接远程I/O系统到DCS, 能够减少接线, 还能够节省时间、节约成本和减少工作量。
P+F公司的LB系列远程I/O具备危险区2区认证, 可安装在Zone 2、Class I、Div.2或者非危险区域。该模块化的信号调节系统将现场信号关联至非危险区域的控制系统, 连接方式有安全区域现场连接 (NonEx) 和本质安全区域现场连接 (Ex i) 。
金陵石化公司芳烃部新建中间罐区正是采用LB系列的远程I/O系统, 如图1所示。
该系统的底板结构如图2所示。X4为现场总线接口, 用来与DCS通信, 现场实际用于与PX通信;X5为冗余现场总线接口, 用来与DCS通信, 现场实际用于与#3重整通信;X6为服务总线, 用于连接PC机进行相应的组态;X7为扩展机架接口;CHANNEL1/2为通信模块;CHANNEL3-24为I/O卡件;POWER1-3插槽为插相应的供电模块。
2 远程I/O系统的组态过程
(1) 打开PACTWARE, 添加设备, 如图3所示。
(2) 选择添加相应的LB系统, 选择好相应的COM口后选择SCAN SERVICE BUS, 自动扫描网关设备, 如图4所示。
(3) 按照设计图纸在每个通道插入相应的插件, 然后进行具体的点组态, 如图5所示。
(4) 在实际的组态中, 为了通信方便, 处理量程统一设置成0~4095。为了能够与TPS系统通信, 必须对相应的Modbus地址进行分配, 如图6所示。点击Auto marshalling按钮, 系统会自动根据卡件的通道号分配相应的地址。组态结束后, 对相应的系统进行下载。
3 与DCS通信
LB远程I/O系统与Honeywell TPS系统采用的是标准的Modbus-RTU通信协议。
控制器和主机为主从关系。仅一设备 (主设备) 能初始化传输 (查询) , 其它设备 (从设备) 根据主设备查询提供的数据做出相应反应。这种传输方式也使得信号在Modbus网络中的通信井然有序。
根据系统的特点, 采用RS-485接口, 接口采用平衡驱动器和差分接收器的组合, 使用屏蔽双绞线传输 (一般只需二根连线) 数据, 抗共模干扰能力增强, 抗噪声干扰性好。
将现场远程I/O系统的通信线连接DCS中的SI卡FTA板, 在DCS中组态相应的ARRAY点, 设置地址、波特率、通信协议, 分别如图7、图8、图9所示。
建立相应的通信之后, 要对模拟量点的量程进行转换, 以达到实际使用要求。
4 结语
远程I/O系统不但节省成本, 减少工作量, 而且可以在线对参数进行修改, 在线监测功能强大, 利于故障的判断, 减少了维护量。
参考文献
[1]丁宝苍.过程控制系统与装置[M].重庆:重庆大学出版社, 2013
[2]乐嘉谦.仪表工手册[M].北京:化学工业出版社, 2003
[3]厉玉鸣.化工仪表及自动化[M].北京:化学工业出版社, 2011
[4]张春华, 肖体兵, 李迪.工程测试技术基础[M].北京:机械工业出版社, 2011
[5]王树青, 乐嘉谦.自动化与仪表工程师手册[M].北京:化学工业出版社, 2010
[6]武平丽, 高国光.过程控制工程实施[M].北京:电子工业出版社, 2011
CC2530普通I/O口的扩展 篇8
1 CC2530的I/O口扩展方法的总体思路及各组成工作原理
1.1 CC2530的I/O口扩展方法的总体思路
本扩展方法采用CC2530的I/O口模拟IIC总线的SCL和SDA, 通过IIC总线控制PCA9554芯片, 使串行通信变成并行通信。从理论上来讲CC2530芯片P1口的8个I/O口就可以连接4组IIC通信, 每组因扩展芯片地址A2A1A0的不同可同时支持8个芯片, 每个芯片又可控制8个端口。因此, CC2530的P1口从理论上就可支持128个 (4×8×8) 端口, 如图1所示。并且, 如果芯片固定的头地址不一样的话, 例如PCA9554和PCA9554A, 那么端口数量又可增加一倍, 这样P1口就扩展成了256个端。依此类推CC2530的I/O口通过扩展数量呈几十倍的增加, 可大大丰富I/O口的应用。
1.2 IIC总线工作原理
IIC总线只有两条线, 一条是数据线SDA, 另一条是时钟线SCL。数据线SDA在时钟线SCL的控制下可串行发送和接收数据, 传送速率最高达100kbps。各被控制器件均并联在这两条线上, 每个接到IIC总线上的器件都有唯一的地址, 通过不同地址决定通信对象, 如图1所示。这样, 各控制电路虽然挂在同一条总线上, 却彼此独立, 互不相关。IIC总线的优点是占用的空间非常小, 可避免线路互连而使电路板走线错综复杂的现象, 减少了电路板上的布线空间, 降低了互联成本。
IIC总线上只有四种信号:开始信号、停止信号、重新开始信号和应答信号。IIC总线上能实现主/从双向通讯, 器件发送数据到总线上, 则定义为发送器, 器件接收数据则定义为接收器。主器件和从器件都可以工作于接收和发送状态。IIC总线时序如图2所示。
1.3 PCA9554工作原理
PCA9554是带中断的GPIO扩展芯片, 它提供了IIC总线方式应用中的8位串行转并行输入/输出口的扩展。PCA9554共有4条命令, 在总线主控制器 (本文中为CC2530) 向PCA9554发送写数据过程中, 命令字节是紧跟地址字节, 之后第一个字节作为一个指针指向要进行写或读操作的寄存器。CC2530通过总线写I/O口的相应配置位来激活端口的输入或输出。通过给PCA9554的A2A1A03个管脚不同的电平来实现不同IIC地址, A2A1A03个管脚可组成8个地址码, 由此总线上最多允许挂8个PCA9554。而PCA9554与PCA9554A的IIC固定地址不同 (PCA9554的固定地址为01000A2A1A0, PCA9554的固定地址为01110A2A1A0) , 这样就允许16个器件 (PCA9554和PCA9554A各8个) 连接到同一个IIC总线上, 每个器件扩展出8个I/O端口, 这样CC2530的两个I/O端口就可扩展到8x16个I/O口。
2 扩展I/O口的应用
本应用通过CC2530的I/O口 (P1.0和P1.1) 模拟IIC总线的SCL和SDA, 然后通过IIC总线形式控制GPIO扩展芯片PCA9554, 最后通过扩展的IO来控制LED、蜂鸣器、按键信号、继电器等, 如图3、4所示。
3 结语
本文通过IIC总线形式控制GPIO扩展芯片PCA9554扩展CC2530的I/O口。在文主要提出了具体的硬件设计, 并运用于实践中。CC2530的I/O口进行扩展, 使I/O口的数量大大增多, 能丰富开发设计者的运用。
参考文献
[1]施邦平.采用I2C器件扩展单片机的多级通信[J].自动化与仪器仪表, 自动化与仪器仪表, 2006 (6) :63-64.
智能化I/O 篇9
关键词：I/O性能,流,缓冲区,分配和回收
Java应用程序都会经常使用java.io包, 例如磁盘文件读写和通过网络传输数据。然而初学者由于对java.io包的理解的局限性导致编写的程序I/O性能很差。所幸的是, 只要对java.io包有了很好的理解, 就可以杜绝这方面的问题, 从而保证程序拥有较好的I/O性能。
本文首先对java.io包做一个简要的介绍, 然后指出导致I/O性能低下的根本原因是没有采用缓冲机制, 然后循序渐进地采取了三种策略, 将I/O性能逐步提高到168倍, 这三种策略分别是采用缓冲流, 定制自己的缓冲区, 定制静态的固定长度的缓冲区。
1 I/O操作的基本概念
在Java I/O中最基本的概念是流 (Stream) , 流是一个连续的字节序列, 包括输入流和输出流, 输入流用来读取这个序列, 而输出流则用来写这个序列, 在默认情况下Java的流操作是基于字节的, 即一次只读或只写一个字节。
java.io包提供了Input Stream和Output Stream作为对I/O操作的抽象, 这两个接口决定了类层次结构的基本格局。Input Stream和Output Stream的具体实现类提供了对不同数据源的访问, 如磁盘文件和网络连接。
java.io包还提供了过滤流 (Filter Stream) , 过滤流并不指向具体的数据源, 而是在其他流之上进行了包装, 这些过滤流其实是java.io包的核心。从性能的角度来看, 最重要的过滤流是缓冲流 (Buffered Stream) , 图1显示了一个简化的类层次结构图。
2 缓冲流
导致I/O性能低下的主要原因是没有对I/O操作进行缓冲。众所周知, 硬盘擅长于大块数据的读写, 但是在小量数据的读写上性能不好, 所以, 为了最大化I/O性能, 我们应该选择批量的数据操作, 而缓冲流正是为这个目的设计的。缓冲流, 包括Buffered Input Stream和Buffered Output Stream, 它为I/O流增加了内存缓冲区, 使得Java程序一次可以向底层设备写入或者读取大量数据, 从而提高了程序的性能。
为了更好地理解缓冲流的效果, 请阅读程序清单一, 这个例子采用了原始的文件流实现文件的拷贝。copy方法打开了一个File Input Stream和一个File Output Stream, 并将数据从一个流直接拷贝到另一个流。由于read和write方法是基于字节的, 所以实际的磁盘读写也是按字节发生的。实践证明使用这段代码拷贝一个8M的文本文件需要花费36750ms。
程序清单一中的copy方法只需稍作修改就能有效地改善性能, 如程序清单二所示, 它在原始的文件流之上采用了缓冲流Buffered Input Stream和Buffered Output Stream, 缓冲流将每一个小的读写请求积攒起来, 然后一次性地批处理, 通常是将几千个读写请求合并成一个大的请求。改进后的copy方法拷贝一个8M的文本文件需要花费1187ms, 性能大约提高了31倍。
3 建立自己的缓冲
缓冲流虽然在它的内部增加了内存缓冲区, 使得在缓冲区和底层设备之间写入或读取大量数据成为可能[2,3], 但是在这之上Java程序仍旧使用while循环从该流 (实际上是缓冲数组) 按字节读写数据。由于缓冲数组的大小是一定的, JVM需要针对数组做越界检查, 该操作会导致额外的系统开销。另一方面, 为了支持多线程环境, 将数据从Buffered Input Stream的缓冲数组拷贝到Buffered Output Stream的缓冲数组, 其中的方法调用很多都是synchronized, 这也会导致额外的系统开销。所以尽管程序清单二所示代码可以有效地改善性能, 但是改善的程度仍然不尽人意。
还是利用硬盘擅长读写大块数据这一特性, 我们可以自己建立缓冲, 以避免上述额外的系统开销。这需要使用Input Stream和Output Stream提供的两个重载方法, 它们允许按字节读写, 也可以按字节数组读写, 如下所示:
程序清单三创建了自己的缓冲区, 即字节数组byte[]buffer, 其大小是整个文件的字节长度, 然后将整个文件一次性读入内存, 再一次性写到另一个文件。这个代码非常快, 拷贝一个8M的文本文件所花费时间降低到750ms。
注意, 使用这个策略需要权衡两个因素。首先是缓冲区的大小, 它所创建的缓冲区的大小等于被拷贝的文件大小, 当文件很大时, 该缓冲区也会很大。第二, 它为每次文件拷贝操作都要创建一个新的缓冲区, 当有大量文件需要拷贝时, JVM不得不分配和回收这些大缓冲区内存, 这对程序性能是极大的伤害。
如何在保持速度甚至速度更快的前提下避免这两个缺陷呢?方法是这样的:创建一个静态的固定长度的字节数组, 如1024*1024字节即1M, 每次只读写1M的数据。虽然对于大于1M的文件会需要多次读写才能完成整个文件的拷贝, 但是这样避免了内存的反复分配和回收。缓冲区大小是可以调整的, 针对某个具体的应用场景, 我们可以在速度和内存之间取得一个最佳的平衡。
程序清单四的copy方法使用了这样的1M字节的数组, 这个版本表现更为出色, 它拷贝一个8M的文本文件所花费时间只有218ms, 性能提高了168倍。
值得注意的是代码中的同步块, 在单线程环境下没有同步块是可以的, 但是在多线程环境下需要同步块防止多个线程同时对缓冲区实施写操作。尽管同步会带来系统开销, 但是由于while循环的次数很小 (8M文件只要循环8次) , 所以由此带来的性能损失是可以忽略不计的。实验证明, 有同步块的版本和去掉同步块的版本, 性能是一样的。
下表显示了采取四种不同的策略拷贝一个8M文件所花费的时间。它充分说明, 有效地改进缓冲机制可以大大提高程序的I/O性能。
4 结束语
一般情况下, 我们总可以为具体的应用程序找到改善I/O性能的方法, 这需要具体分析该应用程序的目的和操作特性。例如, 考虑FTP和Http服务器, 这些服务器的主要工作就是将文件从磁盘拷贝到网络的Socket, 一个网站的主页通常比其他网页访问得更多。为了提高性能, 我们可以建立快速缓冲贮存区, 将那些经常被访问的文件做缓存, 这样这些文件就不必每次从磁盘读写, 而是直接从内存拷贝到网络。
参考文献
[1]What is Java I/O?[EB/OL], http://www.roseindia.net/java/example/java/io/Java_io.shtml
[2]Buffered Input Stream, JavaTM Platform Standard Ed.7[EB/OL], http://docs.oracle.com/javase/7/docs/api/java/io/Buffered Input Stream.html