松原西门子200地区代理商厂家

操作定时器，包括使能位、直接赋定时值、R指令复位等，指令执行后立即生效，不是等到系统刷新时。

这和系统对定时器的刷新机制不冲突，也不矛盾的。

读定时状态位、当时定时值，读到的就是较新鲜的值，包括由操作定时器指令立即产生的结果。但读指令本身不会改变定时器的状态。

前几天看到一个提问是这样的问为什么C0不计数？而把网络1和网络2交换就可以了？

这个问题对于新手来说是一个很*犯的错误，我自己也犯过同样的错误。那是因为手册中有段话把我误导了，也是自己对它理解不够。

这个问题对于新手来说是一个很*犯的错误，我自己也犯过同样的错误。那是因为手册中有段话把我误导了，也是自己对它理解不够。

就是这个程序，我的想法是I0.0是按钮，按下Q0.0接通，在按下Q0.0断开，可实际Q0.0根本不会接通。那么问题来了，手册中这样说的

就是这个程序，我的想法是I0.0是按钮，按下Q0.0接通，在按下Q0.0断开，可实际Q0.0根本不会接通。那么问题来了，手册中这样说的

就是这个程序，我的想法是I0.0是按钮，按下Q0.0接通，在按下Q0.0断开，可实际Q0.0根本不会接通。

那么问题来了，手册中这样说的

我的程序应该I0.0上升沿时Q0.0置位，但要等到扫描完时才会输出Q0.0，那么网络2的I0.0上升沿后面Q0.0就应该为OFF，那么就不会复位，下次按下I0.0时Q0.0复位。应该没问题啊。

我的程序应该I0.0上升沿时Q0.0置位，但要等到扫描完时才会输出Q0.0，那么网络2的I0.0上升沿后面Q0.0就应该为OFF，那么就不会复位，下次按下I0.0时Q0.0复位。应该没问题啊。

而**个程序是这样的，说明书上说10ms定时器在扫描开始时刷新，那么当T98 ON的那一个扫描周期计数器就应该计数啊。难道说明书有问题？后来自己仔细研究才明白，CPU执行程序时用的是过程映像寄存器中的值，Q0.0那个程序就好理解了，置位Q0.0后，寄存器中Q0.0已经ON了，扫描网络2的时候读取寄存器中Q0.0 ——>ON,所以I0.0上升沿——>ON,Q0.0——>0N，所以Q0.0被复位，Q0.0输出OFF。那定时器这个呢？我在想cpu读取的应该也是寄存器中的值而不是定时器的实际地址，所以实际就是扫描开始读取T98实际地址传送给T98寄存器——>T98寄存器ON网络1  扫描到T98时——>T98寄存器off网络2  T98寄存器OFF，所以网络2的T98永远接不通。这只是我的个人理解，实际是不是这样运算的也没找到资料，想到了电脑CPU的缓存，是不是plc的过程映像寄存器是一个道理。经过我的消化，是这样理解的：1、与定时器有关的指令，可以分两类，一类是使用定时数据的，另一类是操作定时器的。就象一个闹钟，读时间就是使用闹钟，拨弄闹钟就是操作。2、使用定时器，也就是读定时器状态或定时器当前的时间值，对定时器是没有影响的，而操作定时器，则会影响定时器的状态及当前值，而且是若有影响，立即生效。所以T38，定时到时，又被立即复位了，T38=1的状态到不了下面的网络。

而**个程序是这样的，说明书上说10ms定时器在扫描开始时刷新，那么当T98 ON的那一个扫描周期计数器就应该计数啊。难道说明书有问题？后来自己仔细研究才明白，CPU执行程序时用的是过程映像寄存器中的值，Q0.0那个程序就好理解了，置位Q0.0后，寄存器中Q0.0已经ON了，扫描网络2的时候读取寄存器中Q0.0 ——>ON,所以I0.0上升沿——>ON,Q0.0——>0N，所以Q0.0被复位，Q0.0输出OFF。那定时器这个呢？我在想cpu读取的应该也是寄存器中的值而不是定时器的实际地址，所以实际就是扫描开始读取T98实际地址传送给T98寄存器——>T98寄存器ON网络1  扫描到T98时——>T98寄存器off网络2  T98寄存器OFF，所以网络2的T98永远接不通。这只是我的个人理解，实际是不是这样运算的也没找到资料，想到了电脑CPU的缓存，是不是plc的过程映像寄存器是一个道理。经过我的消化，是这样理解的：1、与定时器有关的指令，可以分两类，一类是使用定时数据的，另一类是操作定时器的。就象一个闹钟，读时间就是使用闹钟，拨弄闹钟就是操作。2、使用定时器，也就是读定时器状态或定时器当前的时间值，对定时器是没有影响的，而操作定时器，则会影响定时器的状态及当前值，而且是若有影响，立即生效。所以T38，定时到时，又被立即复位了，T38=1的状态到不了下面的网络。

而**个程序是这样的，说明书上说

10ms定时器在扫描开始时刷新，那么当T98 ON的那一个扫描周期计数器就应该计数啊。难道说明书有问题？

后来自己仔细研究才明白，CPU执行程序时用的是过程映像寄存器中的值，Q0.0那个程序就好理解了，置位Q0.0后，寄存器中Q0.0已经ON了，扫描网络2的时候读取寄存器中Q0.0 ——>ON,所以I0.0上升沿——>ON,Q0.0——>0N，所以Q0.0被复位，Q0.0输出OFF。

那定时器这个呢？我在想cpu读取的应该也是寄存器中的值而不是定时器的实际地址，所以

实际就是扫描开始

读取T98实际地址传送给T98寄存器——>T98寄存器ON

网络1  扫描到T98时——>T98寄存器off

网络2  T98寄存器OFF，

所以网络2的T98永远接不通。

这只是我的个人理解，实际是不是这样运算的也没找到资料，想到了

电脑

CPU的缓存，是不是

plc

的过程映像寄存器是一个道理。

经过我的消化，是这样理解的：

1、与定时器有关的指令，可以分两类，一类是使用定时数据的，另一类是操作定时器的。就象一个闹钟，读时间就是使用闹钟，拨弄闹钟就是操作。

2、使用定时器，也就是读定时器状态或定时器当前的时间值，对定时器是没有影响的，而操作定时器，则会影响定时器的状态及当前值，而且是若有影响，立即生效。所以T38，定时到时，又被立即复位了，T38=1的状态到不了下面的网络。

2014年的春节长假刚过的一个周一，刚上班没两天，一切似乎还沉浸在假期的气氛里，少有的清闲。快下班前突然接到一个配套客户主管工程师的电话，说在12年出口波兰的一套由我设计的设备出问题无法生产了，当地的工程师忙活了一礼拜没搞定，让我准备一下马上去波兰。气氛一下有点小紧张，什么情况？设备的确是我设计的，也是我亲自去波兰调试的，那边的设备主管Kaz也是个经验丰富的老工程师，他协助我调试，临走前我把家底儿都交代给他了，所以设备验收都快两年了据说一直不停地在生产，从来没找过我。怎么一下子就搞不定了呢？出啥大事儿啦？挂断电话疑惑了几分钟，紧接着Kaz的邮件也到了，他描述了下故障的现象，并告诉我远程登录设备的账号密码，当年在调试的时候，Kaz就把设备控制系统的上位机（IPC547D有双网卡）接入他们公司的网络，安装了Teamviewer远程联机软件并做了测试，现在终于派上用场了。

事不宜迟，赶快登录上去看看吧。打开了久违而又熟悉的画面，设备一共4个工位，3个都在正常生产，唯*4号工位停机了，心定了，局部问题，没那么严重。接着，检查了所有操作界面，参数界面，报警信息，系统诊断信息没有发现任何的异常，甚至在历史报警归档中都没有找到一条有关于设备的故障信息，啥啥啥都是好好的嘛，搞什么鬼？转念一想，以我对Kaz的了解，他是不会轻易瞎说的，肯定是有问题存在，但这时我也可以很自信地确定，故障与

电气

控制系统之间应该关系不大。一看时间，都7点多了，先下班回家吃饭吧。

一路上都在思考着问题的各种可能性，回到家也是匆匆扒了几口饭，就赶紧到书房打开

电脑

重新连线登录了。又仔细过了一遍操作界面，参数界面，报警和诊断信息，历史故障记录，没有发现任何有价值的信息，同时也再次确定控制系统没有问题。接着打开了生产过程工艺参数的历史记录，查看了4号工位的工况曲线，由于当初在系统程序设计时特意留下了特征数据，历史归档数据也如实地记录下并在曲线上反映了出来，4号工位近2天的记录的确如Kaz所述无法正常工作。看到这里我基本上明白了4号工位不能正常工作的原因，这是个高速线材收卷控制系统，恒线速恒张力控制，系统设计有**卷径保护功能，也就是当实际工作线速度与实际收线轴转速的比值在一段时间内连续**过某个（满卷）设定值时，控制系统就会忽略计长功能的计算值，从而直接自动触发自动换卷功能。这功能是用来防止满卷再绕以及排线装置出问题后导致在一点固定卷绕的现象。但实际上4号工位都是在未满卷状态下就触发了自动换盘功能，一的解释就是收卷轴的转速低了，收线轴的折算线速度曲线对照也反映出了这个问题。

图一：3号工位正常的线速度曲线

图一：3号工位正常的线速度曲线

图二：4号工位异常线速度曲线1

图二：4号工位异常线速度曲线1

图三：4号工位异常线速度曲线2究竟是什么导致收线轴转速慢了，张力控制是正常的，难道是行线速度慢了？牵引是开环控制的，虽然我设计之初强烈要求采用闭环方案，但配套客户还是以各种理由拒绝了，因此牵引的返回线速度实际是驱动器斜坡函数的输出值，这也是收线轴的线速度给定。我虽然强烈的怀疑，但没有任何的证据可以证明牵引线速度出了问题，再说了线速度是重要的工艺参数，对产品品质有重大的影响，Kaz那边也没给我这方面的信息反馈，也只好放一放，从其他方向找原因了。时间飞快的过去了，转眼已是午夜了，还是没有头绪，虽然我很清楚电气控制系统没有问题，但我也没找到明确的证据，明天让我怎么跟客户解释呢？几个小时的烧脑，让我有些困了，这时突然网速一下子快了许多，远程端上位机的反应也快了许多，我精神一振，把历史曲线往前翻了很多天，发现4号工位的生产一直都是正常的，只是在一个星期前有过一次10几个小时较长时间的停机过程，再开机生产就不正常了，这期间发生了什么？还是先发个邮件问问Kaz吧，于是我就回了本文开头的那封邮件…..第二天，**住了配套商打来的好几通催促电话，也是在快下班前收到了Kaz的回复，一切都明白了，我当时较想做的就是把那个趾高气昂的配套商主管工程师摁到马桶里去，当初就是他执意否定牵引的闭环控制方案的….，问题一解决，波兰自然也就去不成了，还有点小可惜！这纯粹是一次偶然，也可以算是我正真意义上的对于设备直接做跨国远程技术诊断的一次实战经历，在2年多前。时至今日，远程协助诊断与调试虽然已经司空见惯，但这大多是在现场有人协助的，而远程直接面对机器设备的调试诊断其实并不如想象中的那么*，几个方面的准备工作要做好，在下面详细介绍：远程直接面对机器设备的调试诊断的准备工作1、要有预先构架好的网络，支持从Internet直接访问到客户工厂里的设备。①现场设备有PC的，可以采用TEAMVIEWER等软件通过远程桌面控制的方式进行诊断和调试，现场PC通过客户网络能够上网，不需要固网IP地址（本案即此例）。②现场没有PC的，可以通过采用*客户端路由器、3G/4G移动网络、客户的有线网络以及*路由器服务器，把不在一地的plc与工程师调试站拉到了同一个内网中。现场客户端只要能上网即可，*路由器服务器侧需要固网IP地址。2、PLC及PC系统要配置有接入远程调试及诊断的通讯接口，应尽量与用于现场设备通讯的接口分开及隔离。3、有了以上的硬件条件后，设置并开通远程接入账号，事先做好连接测试，以备不时之需。4、如果是到现场PC级的远程诊断（如本案），那么现场PC所能够提供的设备信息就尤为重要了，这一般需要通过对现场的PC和plc编程来实现，通常都是将PLC上的信息都尽量传送到现场的PC上，越全面越完善越好，这就需要事先周密地考虑与准备。甚至现场PC也要安装必要的编程组态软件，通过远程桌面控制手段操作编程软件对网络中的PLC进行调试诊断。

图三：4号工位异常线速度曲线2究竟是什么导致收线轴转速慢了，张力控制是正常的，难道是行线速度慢了？牵引是开环控制的，虽然我设计之初强烈要求采用闭环方案，但配套客户还是以各种理由拒绝了，因此牵引的返回线速度实际是驱动器斜坡函数的输出值，这也是收线轴的线速度给定。我虽然强烈的怀疑，但没有任何的证据可以证明牵引线速度出了问题，再说了线速度是重要的工艺参数，对产品品质有重大的影响，Kaz那边也没给我这方面的信息反馈，也只好放一放，从其他方向找原因了。时间飞快的过去了，转眼已是午夜了，还是没有头绪，虽然我很清楚电气控制系统没有问题，但我也没找到明确的证据，明天让我怎么跟客户解释呢？几个小时的烧脑，让我有些困了，这时突然网速一下子快了许多，远程端上位机的反应也快了许多，我精神一振，把历史曲线往前翻了很多天，发现4号工位的生产一直都是正常的，只是在一个星期前有过一次10几个小时较长时间的停机过程，再开机生产就不正常了，这期间发生了什么？还是先发个邮件问问Kaz吧，于是我就回了本文开头的那封邮件…..第二天，**住了配套商打来的好几通催促电话，也是在快下班前收到了Kaz的回复，一切都明白了，我当时较想做的就是把那个趾高气昂的配套商主管工程师摁到马桶里去，当初就是他执意否定牵引的闭环控制方案的….，问题一解决，波兰自然也就去不成了，还有点小可惜！这纯粹是一次偶然，也可以算是我正真意义上的对于设备直接做跨国远程技术诊断的一次实战经历，在2年多前。时至今日，远程协助诊断与调试虽然已经司空见惯，但这大多是在现场有人协助的，而远程直接面对机器设备的调试诊断其实并不如想象中的那么*，几个方面的准备工作要做好，在下面详细介绍：远程直接面对机器设备的调试诊断的准备工作1、要有预先构架好的网络，支持从Internet直接访问到客户工厂里的设备。①现场设备有PC的，可以采用TEAMVIEWER等软件通过远程桌面控制的方式进行诊断和调试，现场PC通过客户网络能够上网，不需要固网IP地址（本案即此例）。②现场没有PC的，可以通过采用*客户端路由器、3G/4G移动网络、客户的有线网络以及*路由器服务器，把不在一地的plc与工程师调试站拉到了同一个内网中。现场客户端只要能上网即可，*路由器服务器侧需要固网IP地址。2、PLC及PC系统要配置有接入远程调试及诊断的通讯接口，应尽量与用于现场设备通讯的接口分开及隔离。3、有了以上的硬件条件后，设置并开通远程接入账号，事先做好连接测试，以备不时之需。4、如果是到现场PC级的远程诊断（如本案），那么现场PC所能够提供的设备信息就尤为重要了，这一般需要通过对现场的PC和plc编程来实现，通常都是将PLC上的信息都尽量传送到现场的PC上，越全面越完善越好，这就需要事先周密地考虑与准备。甚至现场PC也要安装必要的编程组态软件，通过远程桌面控制手段操作编程软件对网络中的PLC进行调试诊断。

图三：4号工位异常线速度曲线2

究竟是什么导致收线轴转速慢了，张力控制是正常的，难道是行线速度慢了？牵引是开环控制的，虽然我设计之初强烈要求采用闭环方案，但配套客户还是以各种理由拒绝了，因此牵引的返回线速度实际是驱动器斜坡函数的输出值，这也是收线轴的线速度给定。我虽然强烈的怀疑，但没有任何的证据可以证明牵引线速度出了问题，再说了线速度是重要的工艺参数，对产品品质有重大的影响，Kaz那边也没给我这方面的信息反馈，也只好放一放，从其他方向找原因了。

时间飞快的过去了，转眼已是午夜了，还是没有头绪，虽然我很清楚电气控制系统没有问题，但我也没找到明确的证据，明天让我怎么跟客户解释呢？几个小时的烧脑，让我有些困了，这时突然网速一下子快了许多，远程端上位机的反应也快了许多，我精神一振，把历史曲线往前翻了很多天，发现4号工位的生产一直都是正常的，只是在一个星期前有过一次10几个小时较长时间的停机过程，再开机生产就不正常了，这期间发生了什么？还是先发个邮件问问Kaz吧，于是我就回了本文开头的那封邮件…..

第二天，**住了配套商打来的好几通催促电话，也是在快下班前收到了Kaz的回复，一切都明白了，我当时较想做的就是把那个趾高气昂的配套商主管工程师摁到马桶里去，当初就是他执意否定牵引的闭环控制方案的….，问题一解决，波兰自然也就去不成了，还有点小可惜！

这纯粹是一次偶然，也可以算是我正真意义上的对于设备直接做跨国远程技术诊断的一次实战经历，在2年多前。时至今日，远程协助诊断与调试虽然已经司空见惯，但这大多是在现场有人协助的，而远程直接面对机器设备的调试诊断其实并不如想象中的那么*，几个方面的准备工作要做好，在下面详细介绍：

远程直接面对机器设备的调试诊断的准备工作

1、要有预先构架好的网络，支持从Internet直接访问到客户工厂里的设备。

①现场设备有PC的，可以采用TEAMVIEWER等软件通过远程桌面控制的方式进行诊断和调试，现场PC通过客户网络能够上网，不需要固网IP地址（本案即此例）。

②现场没有PC的，可以通过采用*客户端路由器、3G/4G移动网络、客户的有线网络以及*路由器服务器，把不在一地的

plc

与工程师调试站拉到了同一个内网中。现场客户端只要能上网即可，*路由器服务器侧需要固网IP地址。

2、PLC及PC系统要配置有接入远程调试及诊断的通讯接口，应尽量与用于现场设备通讯的接口分开及隔离。

3、有了以上的硬件条件后，设置并开通远程接入账号，事先做好连接测试，以备不时之需。

4、如果是到现场PC级的远程诊断（如本案），那么现场PC所能够提供的设备信息就尤为重要了，这一般需要通过对现场的PC和

plc编程

来实现，通常都是将PLC上的信息都尽量传送到现场的PC上，越全面越完善越好，这就需要事先周密地考虑与准备。甚至现场PC也要安装必要的编程组态软件，通过远程桌面控制手段操作编程软件对网络中的PLC进行调试诊断。