根据以上的讨论,我们来开始编写MSG指令。如果希望一条MSG指令不停地反复执行,梯级条件则使用本条指令MESSAGE结构数据标签的使能位Msg_CML.EN的常开输入指令,如图13-4所示。
要让MSG指令按照我们的要求传送数据或执行某些操作,必须对指令进行组态。下面我们来讨论如何对MSG指令进行组态。双击MSG指令中的,打开如图13-5所示的组态页面。页面默认是CIP Generic的组态,这是服务性指令的操作,根据相应的资料提供,对服务类别和指定的服务代码等参数进行设定。
图13-4 连续执行MSG指令的梯级逻辑
图13-5 MSG指令组态页面
我们先讨论Logix控制器之间数据交换的通信,打开Massage Type,如图13-6所示,这里是通信类型的选择,关于其他数据通信的类型,我们不作详细讨论。其中,CIP Data Ta-ble Read和CIP Data Table Write两种通信类型是最常用的,用来完成Logix控制器之间的读写通信操作,我们以此为例来讨论。
选择通信类型CIP Data Table Read,如图13-7所示,是关于本控制器向对方控制器读取数据的通信操作。源数据元素为对方控制器数据标签地址,需要键入对方控制器数据标签地址,目标数据元素为本控制器数据标签地址,可以在本控制器数据区域中已有的数据标签中指定,亦可临时创建。
选择通信类型CIP Data Table Write,如图13-8所示,是关于本控制器向对方控制器写入数据的通信操作。目标数据元素为对方控制器数据标签地址,需要键入对方控制器数据标签地址,源数据元素为本控制器数据标签地址,可以在本控制器数据区域中已有的数据标签中指定,亦可临时创建。
由此看来,不同的数据传送方向,读数据或写数据决定了MSG指令发动控制器的源数据地址和目标数据地址不同,本控制器的数据标签可以在数据库中选定,被访问控制器的数据标签则要键入,有时描述性标签的构成不是特别简单的书写,建议从被访控制器的项目文件的数据库中复制过来,以免键入的微小错误导致MSG指令执行时访问失败,带来调试的麻烦。
图13-6 通信类型的选择
图13-7 选择通信类型CIP Data Table Read
图13-8 选择通信类型CIP Data Table Write
临时创建通信数组标签,点击,进入创建页面,如图13-9所示。注意,作为对外通信的数据标签,该标签要创建在控制器数据区域,且为32位的结构数据标签或数组标签。可以注意到,在MSG组态页面选择本控制器要传送的数据标签时,可供选择的数据区域只有控制器数据区域,程序数据库区域是灰色的不可选择的。
数组标签创建的元素个数应该大于等于MSG指令要传送的数据元素个数,否则MSG指令执行时,将由于操作数组元素不足而报错。
图13-9 新标签创建页面
组态完成的页面如图13-10所示。要特别注意的是,选择源数据标签地址和目标数据标签地址时,必须是要传送的数组标签指定的首个元素,而不是单一的数据标签名称,然后在元素数目的栏目Number Of Element中键入要传送的元素个数。这样,首址加要传送的元素个数概括了数组中被传送数据的范围。如果不小心写成了单一的数组标签名称而没有指定首个元素编号,在较高控制器版本的系统中将默认为首个元素是0号元素,较低控制器版本的处理则可能是只传送第一个元素,后面的元素不予传送,一定要留意这一点。
刚才的组态页面只指定了相互通信的两个控制器的源数据标签地址和目标数据标签地址,并没有指定信息通信的路径。路径有一定的结构规则,由一个或多个路段构成,路段复杂时可以通由不止一个网络,甚至可以是不同类型的网络,这也是MSG指令传送灵活的特点之一。
MSG指令通信组态要填写通信的路径,路径的书写规则是:
●一条路径由多个路段组成,每个路段的表达是X,Y。通常一条从本控制器出发到达对方控制器的路径会表达为
图13-10 组态完成的组态页面
●X表示背板或网络,背板为1,网络为2。
●Y表示槽号或站号,槽号在0~16之间,站号则不同网络的表达形式不同:
ControlNet 1~99十进制
DH+ 00~77八进制
EtherNet/IP IP地址
点击进入通信组态页面Communication,如图13-11所示。这里指定的通信路径是从一个CompactLogix控制器出发,到达一个IP地址为192.168.1.111的另外一个CompactLogix控制器所经历的路径,两个控制器都位于背板总线的0槽。信息出发的控制器即为MSG指令发动的控制器,信息路径与数据传送方向无关,不论MSG指令的操作是读信息或是写信息,路径总是从MSG指令发动的控制器指向被MSG指令访问的控制器。
图13-11 MSG指令的通信组态页面
在通信组态页面,填写从MSG信息发动的控制器出发,直至到达对方控制器的所经过的路径。这种路段书写规则,不仅仅使用在MSG指令,在一些产品的访问路径上也都在使用,但路段的隔离符号却略有差异。MSG指令所使用的隔离符号是逗号,有的产品则使用空格或分号作为分隔符号。
Cache Connections是缓存式连接,此项被勾选,表示这条MSG指令固定的占用一个控制器的连接;如果取消,表示只有在运行这条MSG指令时才会占用控制器的连接。前面讨论的MSG指令执行状态就包含了此项的设定。
缓存式的连接在控制器中都是有限量的,每个控制器不能超过32个,这意味着如果这种通信类型的MSG指令在同一个控制器中的使用要超过限量,就不得不取消Cache Connec-tions的选项,编制轮流执行MSG指令的梯级逻辑,并互锁执行。这32个缓存式连接是包含在控制器总连接数中的,也就是说,MSG指令每消耗一个缓存式连接的同时也消耗了控制器的一个连接。
另外,容易被误解的是,以为控制器被限于只有32条MSG指令可执行,实际上是被限于只有32个缓存式连接,除了Logix控制器之间CIP式的通信类型和块传送会要占用缓存式连接,服务性指令和与传统产品处理器通信的MSG指令并不占用缓存式连接。不是说非CIP式的通信类型便可节省控制器通信资源,它们只是不占用缓存式连接的资源,却要占用非连接缓冲区的连接,那里的资源更为紧张,在这里我们不作深入的讨论。
仅仅是从控制器通信资源受限的角度来看,当为数不少的MSG指令需要发送时,不得不认真考虑如何编写指令执行的梯级逻辑,否则将造成通信的障碍,令MSG指令不能成功执行。下面我们讨论如何通过梯级逻辑的控制来安排MSG指令的执行。
如果需要几条MSG指令互锁执行,只要按照如图13-12所示的梯级逻辑编写就可以了,注意梯级条件的输入位逻辑的顺序,将本条指令的EN常开位放在离指令最近的位置,其他指令EN常开位则按照本条指令之后的执行顺序排列在前面。这样的编写,可使得指令的执行顺序是:Msg—CML1→Msg—CML2→Msg—CML3
图13-12 互锁按序的MSG指令执行
这种编程方法不仅仅适用于MSG指令,只要是希望指令依照顺序反复执行,大都采用这样的编程方式,在编程基础的章节中,我们曾经讨论过。这里是MSG指令执行的实例,在MSG指令不多的情况下,这是通常的做法,可以保证MSG指令的顺畅执行。
图13-13 指针控制MSG指令执行的进程(www.xing528.com)
图13-13 指针控制MSG指令执行的进程(续)
如果有更多的MSG指令需要互锁执行,梯级逻辑的输入指令部分则显得繁杂,不妨采用指针的方法来控制进程,如图13-13所示是常用的一种梯级逻辑编写实例。
设定0.5s传送一条MSG指令,如果网络正常,足以保证MSG指令能传送成功,所有数据传送一遍的周期需要3s时间。这样的编程适合数据交换周期时间长,没有苛刻的时间限制,一旦某条MSG指令传送不成功,不会影响到下一条MSG指令的传送。如果通信页面设置的Cache Connections项是被取消的,这么多的MSG指令传送只会占用1个缓存连接。此外,每条MSG指令梯级条件的维持时间是0.5s,要确认MSG指令是梯级条件跳变才会执行的,所以这样的梯级条件不会令MSG指令不停地被触发。
如果为了紧凑地使用通信时间,高效率地传送数据,让MSG指令一条接一条的执行,又要保证前一条确定执行完毕才执行下一条MSG指令,则要利用MSG指令的状态位来控制进程了。梯级逻辑的编写如图13-14所示。
这种编程方式,前一条执行完成位置位才可以令下一条MSG指令的梯级条件成立,其风险是,一旦其中一条MSG指令执行有问题,那么所有的MSG指令都没法继续执行。这种应用只适合的场合为:任一条MSG指令没有送出,其他MSG指令的传送将变得没有意义。
第一条MSG指令用初始位S∶FS触发,也可以用复位位Reset_MSG来触发,之后便进入6条指令轮流执行的循环之中。复位的操作时间不能超过6条MSG指令执行的循环时间,否则会产生执行顺序问题。这在人工操作中是难以控制的,所以要用ONS指令来确保短脉冲操作动作。
前一条MSG指令执行后的完成位将作为本条MSG指令的梯级条件,执行本条MSG指令并复位梯级条件的完成位,然后进入下一条MSG指令的执行。
图13-14 MSG指令的连续执行
考虑到某条MSG指令发生错误而引起的卡壳现象,即使错误已经消除,但是曾发生错误的MSG指令已经失去了梯级条件触发复位ER的机会,使得后面的MSG指令不能继续执行。不妨编写一条梯级逻辑用来探测各条MSG指令的错误,并设置提示位MSG_Error,当看到错误提示位置位后,可操作复位Reset_MSG来恢复正常的运行,如图13-15所示。不要试图用提示位MSG_Error作为并行的梯级条件来直接复位,这可能给你带来意想不到的麻烦。
图13-15 MSG指令错误提示
从以上3个实例讨论可以看出,如何安排MSG指令的执行顺序完全取决于通信需求,在满足需求的前提下,尽可能地减轻控制器的通信负担,节省控制器通信资源。
有时会遇到在同一个控制系统内主控制器向所有从控制器发布相同信息的应用,那么我们可以巧妙地运用修改通信路径的方法来实现。MESSAGE结构数据中的一个子元素是用来存放通信路径的,如图13-16所示。通过编写逻辑代码执行替换这个子元素,也就替换了MSG指令的通信路径。
图13-16 MSG指令通信路径子元素
首先创建一个用户自定义的字符串数据类型,长度为30个字符,比可能用到的路径字符串要更大一些,用来存放书写通信路径的ASCII码数据。对于同一个网络的MSG信息路径描述,30个字符基本就足够了,如图13-17所示。MESSAGE结构数据标签路径子元素的字符串长度是82个字符的STRING类型,我们没有必要定义这么长的字符串数据类型,满足需求就好,尽可能节省内存空间。
在数据区创建6个元素的数组标签,选择数据类型为刚刚创建的STRING_MSG_PATH,并在数据输入的字符串面板中键入将要使用的路径描述。如果对键入的字符串数据没有把握,可以从通过组态页面已经产生的路径子元素复制而来,然后局部修改。如图13-18所示是在数据表中已经创建并键入的字符串数据的数组标签,它将用于主控制器对6个从控制器访问的路径描述。
图13-17 定义MSG通信路径的结构数据
图13-18 创建有关的通信路径标签
编写的梯级逻辑如图13-19所示,仍然采用指针控制的方法,根据不同的指针判定,确定复制某个新的路径给MSG指令结构数据标签的路径子元素。此例将指向6个不同IP地址的从控制器,用累加计数修正指针,轮流对从控制器传送数据,每逢6便复位指针,重新开始下一轮数据传送。
建立一个自复位的定时器,每0.3s产生一个DN,作为指针增量操作动作,并同步传送一次数据。对所有的从控制器通信共同使用一条MSG指令,每当指针增加一次,MSG指令便执行一次,将指定的数据内容送往指令通信路径所指向的从控制器。
勾选MSG指令通信页面的Cache Connections项,让MSG指令的通信固定地占用一个缓存连接。
请留意COP指令的长度,这里是复制路径字符串的数据的个数,从第一个开始,直到描述结束,这个长度可以自己算出,简单的办法是直接到数据库去读取一个指令当前的字符串数据,如图13-20所示。用这个方式直接且结果正确,不必纠结中间字符是否算数。
其实,稍稍研究一下COP指令的源地址和目标地址会觉得有点问题,如果目标地址是Msg_Master_CML.Path,这是MESSAGE结构数据标签的一个子元素,源地址Msg_Master_Path_Buffer是数组标签的一个元素,COP指令的长度应当为1才对,是一个元素的复制操作,但这两个元素的字符长度是不一致的。这样看来似乎目标地址用Msg_Master_CML.Path.DATA[0]才对,COP指令的长度就是字符个数,如此一来,源地址又怎么表达它的首址呢?只好测试一下了,结果如图13-19所示的那样,直接将Msg_Master_CML.Path作为目标地址,在Msg_Master_CML.Path中可观察到目标地址的变化是正确的。
图13-19 修改通信路径对不同的从控制器发送MSG
图13-19 修改通信路径对不同的从控制器发送MSG(续)
图13-20 获取路径子元素的长度
可惜最终的MSG指令执行没法测试,6个从控制器的通信路径访问只能到现场去印证了,好在我们有了一条MSG指令访问一个控制器的测试经验,即使现在MSG指令给出ER错误提示,我们仍然能预测到正确的结果。这个实验只是帮助我们了解通信路径是否能动态修改,从而编写简单的MSG指令。
MSG指令的组态页面设置如图13-21所示。在接收主控制器信息的每个从控制器中,最好创建名称和结构都相同的数组标签,比如标签名为From_MasterController的主控制器目标地址的数据标签。
在从控制器一方创建名称和结构都相同的数组标签,为组态页面提供一个固定的地址自然是方便简洁,但是如果不得不修改目标地址,也是可以做到的,控制结构数据标签中还有一个子元素是描述对方控制器数据标签地址的,如图13-22所示。
图13-21 MSG指令的组态页面设置
图13-22 描述对方控制器数据标签地址的子元素
这样,在同一个梯级中就必须同时有两个子元素COP,如图13-23所示。
图13-23 路径和对方控制器标签的复制
当然,跟创建通信路径标签数组的做法一样,在数据库中事先也要创建相应的标签数组Msg_Master_RemoteElement_Buffer,并设置对方控制器数据标签地址的字符串数据。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。