|
1.应用的基本信息 1.1 基本应用信息描述(您所经历过的现场或案例,描述设备运行的异常情况,语言简要、故障要点突出,现象表达清楚,涉及具体设备的版本信息,网络规模,主要产品列表等)
是铜板厂的一个项目,设备已经调完了还需跟上位的dcs打通数据,plc是1511,DCS是和利时。现场的朋友没搞过ModbusTCP于是求助我想让我远程帮忙。虽然我也没有应用ModbusTCP的实际案例但是早年间应用ModebusRTU的案例数不胜数。判断问题不大,所以吹了个小牛,跟朋友说这是小Case分分钟搞定。后来的事实证明话不要说满,事不要想当然,好在朋友并没有戳穿出糗的我。
DCS厂家提出要求说他们做主站PLC做从站。但是博图中只有ModbusTCP服务器和ModebusTCP客户端,并没有主站从站,所以找DCS厂家确认,得到的答复是DCS做服务器,PLC做客户端。这还不简单,指令拖出来引脚一填,好了测试吧。“怎么样”,“不通”,“现在呢”,“不通”,“再试试”……此处省略一万字。总之折腾了好久通不上,一怒之下在网上找了个测试软件,对着PLC测,PLC这边一测就通。那还说啥,我没问题啊,全怪DCS害我折腾半天,去让他也下个测试软件,把他那头测通再联调吧。时间也晚了让朋友从现场撤了,等第二天DCS改好了再测。
第二天听朋友说DCS那边下了个测试软件,不知是不会用还是啥原因一直测不通,结果他也怒了,一怒之下居然去找客户告状……原因是再另一个车间有一个1200和他们的另一个DCS通得好好得,两个DCS设置一摸一样,那一定就是我们这个1500得问题了。好吧无话可说。关键客户还吃这一套,埋怨选了个1500没选1200。
其实也习惯了,扯皮得事交给他们吧,我还是想想怎么解决通讯问题。突然发现我测试ModebusTCP客户端得软件叫ModbusSlave。从网上下得时候也没注意,现在一看不对啊,怎么用从站测从站?难道ModbusTCP客户端是主站?顺着这个思路查找资料很快找到了问题。本来TCP/IP通讯是没有主从表述得,如果硬要说,那么服务器是从客户端是主。修改程序,改成服务器,通讯立马好了。
2.故障的检测和解决
2.1 故障或问题分析(根据故障或问题,进行分析,从而提出潜在的一些解决方案用于解决该问题)
与其说故障更不如说是双方工程师沟通不到位认识不全面。
2.2 故障或问题处理(根据分析各种导致故障的可能性,逐步排查,描述您解决此问题的操作步骤,最终确认原因,排查过程有条理,思路清晰)
例如,可能由于编程所导致的通信中断,那么解决步骤是在线查看功能块出现的故障代码,查看手册,修改程序等等。
3.实践联系理论
485总线中主站轮询从站,是主动得一方。
TCP/IP中客户端访问服务器,客户端是主动得一方。所以客户端是主,服务器是从。
但是从对应关系上来看,一主对多从,而一服务器对多客户端。这是最初被误导得一个原因。
TCP/IP得关系表述还是得用服务器和客户端,主从容易产生歧义。
问题没有头绪时,可以质疑问题本身。
|
|