西门子模块6ES7313-5BG04-0AB0 西门子模块6ES7313-5BG04-0AB0
PLC执行程序过程中,可能会用到顺序控制。顺序控制继电器就是根据顺序控制的特点和要求设计的。顺序控制继电器区是S7-200CPU为顺序控制继电器的数据而建立的一个存储区,用S表示。在顺序控制过程中,用于组织步进过程的控制。 可以按位、字节、字、双字四种方式来存取。 (1)按“位”方式:从S0.0~S31.7,共有256点。 (2)按“字节”方式:从SB0~SB31,共有32个字节 (3)按“字”方式:从SW0~SW30,共有16个字 (4)按“双字”方式:从SD0~SD28,共有8个双字6ES7 312-1AE13-0AB0 | CPU312,32K内存 |
6ES7 312-1AE14-0AB0 | |
6ES7 312-5BE03-0AB0 | |
6ES7312-5BF04-0AB0 | CPU312C,32K内存 10DI/6DO |
6ES7 313-5BF03-0AB0 | |
6ES7313-5BG04-0AB0 | CPU313C,64K内存 24DI/16DO / 4AI/2AO |
6ES7 313-6BF03-0AB0 | |
6ES7313-6BG04-0AB0 | CPU313C-2PTP,64K内存 16DI/16DO |
6ES7 313-6CF03-0AB0 | |
6ES7313-6CG04-0AB0 | CPU313C-2DP,64K内存 16DI/16DO |
6ES7 313-6CF03-0AM0 | CPU313C-2DP,64K内存 16DI/16DO组合件(6ES7 313-6CF03-0AB0+6ES7 392-1AM00-0AA0) |
6ES7 314-1AG13-0AB0 | CPU314,96K内存 |
6ES7 314-1AG14-0AB0 | CPU314,128K内存 |
6ES7 314-6BG03-0AB0 | |
6ES7314-6BH04-0AB0 | CPU314C-2PTP 96K内存 24DI/16DO / 4AI/2AO |
6ES7 314-6CG03-0AB0 | |
6ES7314-6CH04-0AB0 | CPU314C-2DP 96K内存 24DI/16DO / 4AI/2AO |
6ES7 314-6EH04-0AB0 | CPU314C-2PN/DP 192K内存/24DI/16DO/ 4AI/2AO |
6ES7 314-6CG03-9AM0 | CPU314C-2DP 96K内存 24DI/16DO / 4AI/2AO组合件(6ES7 314-6CG03-0AB0+6ES7 392-1AM00-0AA0*2) |
6ES7 315-2AG10-0AB0 | CPU315-2DP, 128K内存 |
6ES7 315-2AH14-0AB0 | CPU315-2DP, 256K内存 |
6ES7 315-2EH13-0AB0 | |
6ES7315-2EH14-0AB0 | CPU315-2 PN/DP, 256K内存 |
6ES7 317-2AJ10-0AB0 | |
6ES7317-2AK14-0AB0 | CPU317-2DP,512K内存 |
6ES7 317-2EK13-0AB0 | |
6ES7317-2EK14-0AB0 | CPU317-2 PN/DP,1MB内存 |
6ES7 318-3EL00-0AB0 | |
6ES7318-3EL01-0AB0 | CPU319-3PN/DP,1.4M内存 |
西门子S7-200的自由口通信需要通过编程设置串口的工作模式,安排发送和接受指令的触发顺序,还要设定接收的起始和结束条件。对于刚刚开始使用s7-200的电气工程师来说,的确有很多细微处易犯错误。一般碰到客户抱怨通信不上的问题,就要逐一帮客户确认编程配置是否正确。虽然麻烦,不过逐条查下去,总能查到错误所在并解决问题。但是有一次客户遇到的问题颇出人意料,还真耗费了一些时间。
客户反应在编写了自由口通信程序之后,PLC可以发送数据给通信伙伴,但是却收不到任何伙伴方发出的数据。能发送数据给对方,说明通信端口设置没有问题。较有可能是端口被其他通信指令占用导致无法进入接收状态。比如说用常开点调用XMT,或者没有对接收的故障状态进行判断并终止接收,从而导致后续的XMT和 RCV都无法被正确执行。客户表示他的程序并不存在这种情况。但是为了测试问题所在,客户下载了一个仅包含条件触发RCV的程序下去,还是接收不到数据。监控程序RCV指令已被正常执行。
那么是不是接收的起始条件设置不当?客户使用的是起始字符,这并无不妥。并且改成空闲线检测之后,问题依然存在。难道是对方发送的信号有问题?用串口调试软件来测试,是可以接收到的。眼见这几个常见错误都没能cover住这个问题,我只好从头一步步地跟客户确认。但是还是没能发现任何破绽。郁闷之下,只好让客户把程序发过来看看。 **次检查程序的时候还真没注意到问题出在哪里。等到看出来了才觉得啼笑皆非: 不知道大家看出来没有?客户在设定完空闲线时间SMW90和消息定时器溢出值SMW92后,惯性地将接受地较大字符数SMB94也写成了传送字 SMW94。而西门子PLC的高低字节是逆序的,也就是说SMB94为高有效字节,SMB95为低有效字节。见手册中的如下说明: 结果就是较大字符数100被传给了SMB95,SMB95是神马呢?神马也不是,总之与接收条件无关。而真正较大字符数存储字节SMB94被赋值为0。较大字符数都为0了,那当然是接收不到任何数据了。