我不知道你400和300的连接采用的是什么方式,是TCP,还是ISO ON TCP,还是S7? 如果你用的是FC5,FC6进行通讯,如果你的编程习惯很好,你应该就不会出现这样的问题? 我们知道对于通讯来说,好的习惯是首先判断连接的好坏,再进行数据通讯。如果说连接已经不正常了,发送数据还有什么用呢?所以对于SEND/RECIVE通讯,我们可以首先调用FC10(AG_Cntrl)进行连接状态的判断,如果FC10的执行结果是连接已经不正常了,那就通过判断跳过FC5,FC6的执行!这样应该就不会出现以上问题了。呵呵,至于FC10的具体使用可以参考在线帮助。 说到此,不禁感慨一下,真正在我们的编程中有这么好的编程习惯的人有多少呢?包括我在内,一般在程序中实现了功能就行了,至于一些异常情况的处理很少去实现的。记得很早以前有老工程师和我说过,一外国公司在武刚做的一套控制系统,整个异常处理占总程序量的70%,而这70%的程序几乎很少使用,可能一年都用不到1次。但出现异常的时候,如果没有这些程序整个生产就会出现问题。 呵呵,我是做编程出身的,对于编程的问题多说了一些!希望大家不要见怪!!
ISO 协议。多谢您的回答。FC10,我将在接下去的时间中加入这断程序,如果可行,这下可算解决一个大问题了。 还有一个问题 ISO 协议和 TCP-ISO协议那个实时性好。 我们的设备400通过顶上的一个788主战 连接744 744在下接300从战。这样的连接方式。 现场作用TCP-ISO协议延迟很厉害。
quote:[b]以下是引用satanttt在2009-06-09 13:21:04的发言: ISO 协议。多谢您的回答。FC10,我将在接下去的时间中加入这断程序,如果可行,这下可算解决一个大问题了。 还有一个问题 ISO 协议和 TCP-ISO协议那个实时性好。 我们的设备400通过顶上的一个788主战 连接744 744在下接300从战。这样的连接方式。 现场作用TCP-ISO协议延迟很厉害。
不用客气! 因为TCP协议本身是基于字节流的,对于工业控制设备实现起来很不方便,ISO 协议是基于数据包的,对于工业通讯实现起来更简单。ISO ON TCP通讯是在TCP通讯的基础上把数据进行分段和重组,使之符合ISO协议的标准,其底层仍然是TCP协议。所以ISO协议实时性更好一些。但ISO ON TCP的延迟也不应该有这么大吧。是不是无线网络没有设置好!另采用ISO协议就没有延迟吗?或者无线网络的通讯质量不好,从而导致TCP多次重发数据? 另想知道你这个方案是什么行业的?谢谢!
对于S5兼容通讯(Send/Recive),调用FC5/FC6最好不要就直接调用FC5/FC6就完事了。应该按照如下格式进行调用: CALL FC 5 ( ACT := M100.0, ID := 1, LADDR := W#16#100, SEND := P#DB100.dbx0.0 BYTE 240, LEN := 240, DONE := M100.1, ERROR := M100.2, STATUS := MW102 );
R M100.0; SET; A M100.1; JC done; SET; A M100.2; JC err; BEU;//功能块还没执行完,结束程序 done: S M100.0; //功能块执行完了,触发下一次发送 BEU; err: S M100.0;//出错了,也触发下一次发送,这里也可以加入出错处理 BEU;
quote:以下是引用四书五经在2009-06-10 16:16:12的发言: 对于S5兼容通讯(Send/Recive),调用FC5/FC6最好不要就直接调用FC5/FC6就完事了。应该按照如下格式进行调用: CALL FC 5 ( ACT := M100.0, ID := 1, LADDR := W#16#100, SEND := P#DB100.dbx0.0 BYTE 240, LEN := 240, DONE := M100.1, ERROR := M100.2, STATUS := MW102 );
R M100.0; SET; A M100.1; JC done; SET; A M100.2; JC err; BEU;//功能块还没执行完,结束程序 done: S M100.0; //功能块执行完了,触发下一次发送 BEU; err: S M100.0;//出错了,也触发下一次发送,这里也可以加入出错处理 BEU;