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得关系表述还是得用服务器和客户端，主从容易产生歧义。

    问题没有头绪时，可以质疑问题本身。