|
 参加了南宁站的西门子工业通讯嘉年华活动 |
|
参加了7月24日南宁站的西门子工业通讯嘉年华活动。我家在贵州省兴义市，坐了6个半小时的夜班火车赶到南宁，听课时上下眼皮总禁不住地打架，最后终于把课听完了。 首先是以Profinet起头，后面较为详细地介绍了SCALANCE X工业以太网交换机，SCALANCE W无线通信产品。遗憾的是，SINAUT工业远程通信部分被省略了。 我是作水电厂控制的，设备位置都是固定的。听到SCALANCE W无线通信产品在港口RCMS系统、地铁PIS、物流系统、汽车总装线上的种种应用后，感到开拓了眼界。虽说主要应用于移动领域，但细想一下，要把我厂河对岸的水位信号取回来，无线方式应该是很合适的。 至于SCALANCE X工业以太网交换机，我没有听出什么新意来。…… | |
| 阅读全文 | 回复 | 引用通告 |
| MEDOC软件使用中的几个技巧 | |
我手上的MEDOC软件，版本为2.3，DOS下的。 1、如何在已有的程序段中插入空行。先按F2使光标进入程序，再按F7进入编辑模式。需切换insert键，使程序抬头的显示由write变成ins，在相应的梯形图连接处，按下5(|)后，即可插入空行。 2、如何输入含3个操作数的加法。在编辑状态下，选8再选+，软件只接受两个操作数。需在空白处时就直接输入+，跳出编辑框后按F3，后面就可输3个操作数了。对于常量，如3，要写成k3。另要注意，MEDOC软件做得有些古怪，含3个操作数的加法所需的空白长度要多些，否则软件不接受。 3、在Edit->Name下，输入起始的寄存器编号，可查询寄存器是否已被使用。 4、在按下F2、F8后，可按F7进入显示/强制窗口(通过PageUp/Down上下翻)，也可按F5进入变量编辑(通过上下键在Page1/2间切换，两页共可显示16个变量)。 5、我有一套PLC总是报Error，后查出是程序中的D寄存器区域未被定义成掉电保持，上电后自动清零，结果分母为零，程序报错。可在Latch_R中按F2进入编辑，定义需掉电保持的寄存器区域。 | |
| 阅读全文 | 回复 | 引用通告 |
| 三菱PLC模块槽位的计算 | |
我手上的是一套三菱A系列PLC，CPU为A2AS，后面的I/O模块分别是： 16DI---A1SX40-S1(槽位0) 32DI---A1SX41(槽位1、2) 占位----A1SG60(槽位3) 32DO--A1SY41(槽位4、5) AI------A1S63ADA(槽位6、7) AI------A1S63ADA(槽位8、9) Modbus串行通信---A1SJ71UC24-R4-S2(槽位A、B) 16DI---A1SX40-S1(槽位C) 规则： 1、从CPU模块以后开始计算槽位； 2、从零开始； 3、占位模块为1个槽位； 如此，最后一个16DI模块的第一点为XC0 | |
| 阅读全文 | 回复 | 引用通告 |
| 在S7-400 PLC上实现水电站AVC控制 |
|
《AVC功能实现技术说明书》 20073148473.doc(点击浏览该文件) 把AVC部分的也贴出来。希望能与同行多交流。 | |
| 阅读全文 | 回复 | 引用通告 |
| 在S7-400 PLC上实现水电站AGC控制 |
|
《AGC功能实现技术说明书》 20073131846.doc(点击浏览该文件) 一年多了，我终于可以停下来休息一下了。我使用S7-400 PLC开发天生桥二级水电站的AGC/AVC控制程序，目前工作已告一段落，准备进入试用阶段。 天生桥二级水电站是由南方电网直接调度的调峰调频电厂之一。装机6x225 MW，另有500kV开关站(4回)、220kV开关站(10回)各一。为了配合电网的控制要求，要求开发AGC/AVC控制功能。 AGC/AVC程序一般是做在计算机(服务器)上的，而我鉴于电站的实际情况，利用S7-400 PLC来做的。不知道世界上能否找出第二例。嘻嘻，让大家见笑了！ 天生桥二级水电站由于是长隧洞引水发电，机组的震动区在中间区域，范围又较宽，再加上其它的一些限制条件，使得程序开发起来难度很大(对我而言:) )。好在终于熬出头了，程序应该有一定的实用性，当然以后还会不断完善的。 | |
| 阅读全文 | 回复 | 引用通告 |
 南网104实施细则与西门子eRTU具体实现之间存在严重差异(2) |
|
问题2：《南网104细则》中作为基础之一的102号类型，西门子eRTU没有实现。 说明：《南网104细则》在第47页是这样描述应用要求的： “9.5 站召唤和组召唤 象101实施细则一样，仍然采用站召唤和组召唤相结合的方式。刚建立链路后的第一次召唤使用站召唤，而且不能被打断，定时召唤采用分组召唤。…” 站召唤也就是总召唤(类型标识为100)，用于取得厂站端的全部数据，包括数字的、模拟的，带时标的、不带时标的。组召唤的类型标识为102，用于取得厂站端的局部数据，分组策略需双方事先约定。《南网104细则》在第50页给出了具体定义。 我查阅了《104规约文本》，102是用于查询方式收集数据服务的(文本第22页7.2条)，而100是用于总召唤服务的(文本第22页7.5条)。我又仔细查找了《eRTU 104实现》，结果令人失望，第11页明确写到“Read procedure(Type ID 100 and 101 are supported; Type ID 102 is not supported)”，至于不被支持的原因，在第5、7页上注明为“Not implemented and therefore NOT usable in the project”(原来西门子没有实现102类型)。回想我做eRTU通讯测试的过程，确实没有分组的地方。 IEC870-5-104规约是支持平衡传输的，即主站、从站都可以处于主动地位。与此对应的是非平衡传输，即永远是主站问，从站答，只有主站居于主动地位。 我不知道西门子为何不做102类型，但我猜想双方在如何实施平衡传输的技术方向上是不同的。《南网104细则》虽然在第3页的基本规定里明确为平衡方式传输，但是却“坐在平衡传输的椅子上，想着非平衡传输的招儿”。主站仍然采用总召唤和组召唤相结合的方式来收集数据，从站只有主动读负荷曲线数值的份儿(如果从站自己觉得有必要的话)。而西门子的技术措施是透彻的，除了主站的总召，更多的是从站通过背景传输、受时间控制的事件传输、受计数器控制的事件传输等不依赖于主站命令的主动传送。西门子具体定义了7种方式： 1、BaC -- Basic cycle list； (背景传输) 2、Per -- Low level basic cycle list；(低层背景传输) 3、Cc -- Time-controlled list； (受时间控制的事件传输) 4、Coc -- Counter-controlled list； (受计数器控制的事件传输) 5、IL -- Interragation list；(主站召唤) 6、MSPwT -- Telegram buffer list with time(spontaneous list)；(下面两个我不清楚如何使用) 7、MSPnT -- Telegram buffer list without time(spontaneous list)； 从效率上讲，西门子的实现能以“最少的传输量实现最快的反应速度”，而《南网104细则》的思路是以“较多的传输量实现较慢的反应速度”。当然，系统发生连串事故时，西门子的思路可能使主站的通讯开销迅速上升，而南网的则能始终保持一致。 | |
| 阅读全文 | 回复 | 引用通告 |
| 南网104实施细则与西门子eRTU具体实现之间存在严重差异(1) |
|
针对南方电网公司近日制订的104规约实施细则，我详细比较了该细则与我厂拟用的西门子SICAM eRTU装置104规约具体实现，发现存在两处严重差异。这将影响我厂今后对调度通讯如何实施的决策。 问题1：《南网104细则》新增了类型标识为136、137的信息类型，《eRTU 104实现》中不支持。 说明：《南网104细则》在前言中提出“…在不违反IEC60870-5-104(1.0版，2000)和DL634.5101-2002规约结构的前提下，扩展了计划值传送、多点设定值命令等内容…”，随后在第33、34页给出了具体的信息结构定义，其中136报文类型用于AGC同时对多台机组下发设定值，137报文类型用于下发计划曲线(每条曲线含288点，即每5分钟一个点，并通过7字节时标来区分是今天的，还是明天的)。我查阅了《104规约文本》，136、137原本定义为“为将来保留”，现在南网启用并自行进行了定义。但西门子eRTU是无法识别这种用户扩展的报文类型的。 分析：南网的扩展，从概念清晰的角度讲，是有利的。但对于不掌握开发主动权的用户来讲，则是灾难性的。我厂不可能要求西门子公司增加对这种用户扩展报文类型的识别、解析功能，如同我个人无法要求微软公司为我单独添加软件功能一样。从另一方面讲，不作扩展，就在现有框架内仍然可以实现这种应用需求的。比如大家可以约定，起始地址为6701H的，总长为289点的连续信息队列，固定为今日负荷曲线(前面的288点为设定值，第289点一定为0，代表今日)。而其后连续的289点又固定为明日负荷曲线(第289点一定为+1，代表明日)，以此类推。 《南网104细则》已在第50页有类似的结构规划，使用常用的48号类型即可实现(48为归一化类型的设定值命令)，为什么非要扩展出136、137类型来实现呢？ | |
| 阅读全文 | 回复 | 引用通告 |
| 在PC Station中，无法看到CP 342-5从站的信息 |
|
配了一台PC Station，使得Step7 V5.2可以通过以太网，对所有联网的300、400 PLC进行编程和调试。有的300 PLC使用CP342-5模块(CP342-5作DP Slave，且勾上了下面的选项)，挂在另外的300 PLC站上(CPU作为DP Master，另有以太网模块对上连接)。 在PC Station上，可以通过以太网，看见作为主站的300 PLC的情况，却打不开作为从站的，含CP342-5的300 PLC。 在NetPro中编译时，也会有这样的Warning "On the PROFIBUS subnet 'PROFIBUS', there are additional active nodes in other stations that also have to be reloaded."，该如何处理呢？ 今天已解决了这个问题，可能的原因是没有在PC Station与作为上一级主站的300 PLC之间建立S7联接。当我在Application和CPU之间建立一个S7联接，并下载后，就可以看到下一级的300 PLC了(它的CP342-5作为DP Slave)。由于没有作反向测试，所以无法断定。如果与只有一级的300 PLC相联(通过以太网模块)，是无需配置S7联接的。(但这样的做法是否妥当呢？) | |
| 阅读全文 | 回复 | 引用通告 |
 对CP342-5的firmware进行升级 |
|
今天为了解决在PC Station上无法看到下一级300 PLC的问题(是通过CP342-5作为DP Slave，挂在上一级300 PLC的DP总线上)，尝试对CP342-5模块的firmware版本进行了升级。虽然最后证明，这并不是真正的原因，但还是一次有益的尝试。 事先的准备：在Siemens service&support网站上下载CP342-5 firmware的升级文件，以.FWL为文件类型。…… | |
| 阅读全文 | 回复 | 引用通告 |
| 使用CP341完成Modbus通讯的心得与疑问 |
|
需要使用CP341模块，通过modbus协议(CP341为master)，完成与某公司的机组状态在线监测系统的如下任务：送在线监测系统666个机组温度量，取回132个振摆度过大报警信号。本以为这项工作一个晚上可以完成，结果不断出现问题，又多干了一天。 1、使用modbus功能码16，分6次送温度量，每次111个。在线监测系统每次都能正确接收和显示，但每次CP341都报错，OK_counter始终为零，Error_counter每次加1。某公司检查了reply message的内容、顺序都是对的，问题何在？想起FB8(P_SND_RK)和FB7(P_RCV_RK)的Status输出能显示错误代码，顺着代码(08 30H)查相关资料，解释为“reply monitoring time has elapsed”。跑到屏柜后面的CP341细看收发灯，发现每次发信灯闪亮后，大约3秒左右收信灯才会亮。又检查CP341的设置，其中一项为reply monitoring time，缺省为2000ms，原来如此！ 对于111个温度量的报文，该公司的系统为何回答得如此慢，我不得而知。后来，某公司修改了modbus通讯程序，再试后OK了，从灯上判断，对方的reply延时短于一秒，明显加快了。 2、使用modbus功能码1，分6次取报警开关量，每次22个。每次CP341都报错，并且读上来的状态都是off。这回有经验了，直接察看错误代码，这回是从站应答错误。某公司检查了程序源码，果然发现错误，说是长度计算有误，修改后再试OK。 3、通讯正常后，在我这边的监控系统上定义报警信号，完成后又发现与某公司的定义编号对不上，仔细核对发现同一个word中的两个byte是反的，对方的0-7实际放在我的高字节，而8-15又在我的低字节里。我已无心恋战，埋头在自己的PLC程序中将两个字节交换过来。我查看了modbus协议文本，在reply message中应该将同一个word中的低字节放前，高字节置后，不知某公司的程序是不是这样做的。如果他们是对的，问题又出在哪里呢？ 唉，说句长洋人威风的话，每当我使用老外的产品与国内的系统调通讯时，错的总是在国内的系统，我们自己的通讯程序总会有想象不到的问题。另一方面，西门子软件模块设计的诊断代码确实对查找原因大有帮助。 | |
| 阅读全文 | 回复 | 引用通告 |
::日志列表::