由于一些流量積算儀無法找到可以溝通的技術支持人員，有些特性不排除是單獨測試設備的問題或是老產品的問題，故在下面的敘述中，昌暉儀表均隱去流量積算儀品牌，以免不必要的紛爭。以下流量積算儀網絡測試參數均為9600波特率，8數據位，1停止位，無校驗，RS485半雙工網絡，Modbus RTU協議。
1、流量積算儀MODBUS通訊：你慢慢問，否則我要罷工了
在測試上面這個流量積算儀時，通過查閱其手冊，發現我們需要的數據主要放置在從40001到40014(或者說從保持型寄存器0x00到0x0D)這14個連續寄存器中。
在使用PLC或者組態軟件測試之前，昌暉儀表習慣用ModScan測試軟件進行簡單測試。ModScan測試結果正常，能讀取到我們需要的7個數據。ModScan配置如下：
ModScan測試成功后，我們使用PLC直接讀取以上數據，可以讀到正確的數據，但是發現數值變動十分緩慢；進一步監控PLC的通信狀態字，其一直在通信正常、校驗錯誤以及無響應幾種狀態之間不斷切換。由于我們已經讀到正確的數據，故寄存器地址信息和波特率、站號等網絡參數應該沒有問題。
所以首先昌暉儀表工程師對硬件接線進行了檢查，由于只是在辦公室內進行測試，且通信線距離只有50厘米，故測試開始時昌暉儀表未在網絡兩端安裝120歐姆終端電阻，那么既然現在存在問題，我們就把終端電阻加上，畢竟昌暉儀表之前也遇到過某些設備在使用特定材質線纜時在短距離也無法通信的情況。然而，加上終端電阻，甚至更換了一段標準的RS485雙絞屏蔽電纜后，故障依然存在。此時，把儀表的線重新接回計算機用ModScan測試，依然正常。并且，我們把PLC的數據直接用串口監控，發現其和ModScan發出的數據內容一模一樣，就是速度快了一點。ModScan默認情況下一般是1秒鐘發送一次數據請求，但是昌暉儀表測試的PLC主站在默認狀況下，只要從站設備有回復，在3?個字符時間后，就會進行下一次數據請求。會不會是這里的問題呢？
在之前的工作中，昌暉儀表工程師遇到過一些從站設備對通信的處理能力比較弱，或者是程序編制不完善，當485總線繁忙時，由于其處理器計算能力或者程序編制不合理，出現較總線不繁忙時通訊響應遲緩，設備動作卡頓，通訊中斷，甚至設備重啟等情況。僅在今年，昌暉儀表就遇到過一個集控器，主站03報文詢問過快之后設備顯示器停滯不刷新數據；某家電一線品牌的中央空調集控器，速度快但不定時通訊中斷，必須重啟設備才可恢復；某模擬量模塊，速度快后模擬量讀數失真；某壓力表，速度快后直接重啟。
想到這里，昌暉儀表在PLC主站的輪詢邏輯中增加了100ms的延遲時間，即當主站收到從站的正確響應后，等100ms之后再發送下一條請求。驗證，問題得到解決。
2、流量積算儀MODBUS通訊：不要一次問那么多問題，我每次只能回答一點點
在測試上面這臺流量積算儀時，我們同樣首先使用ModScan進行第一步的測試。儀表的協議和地址表如下。
◆讀當前數據
計算機→FC6000(4-8bytes)：$，03H，XXXX，CRC
根據上表，我們在ModScan中做出了如下配置，并且我們在流量積算儀上設置了一個數值為328的質量累積流量值，看看是否可以通信正常。不負所望，ModScan讀出了從地址40003開始的連續14個字的數據，但是結果卻另昌暉儀表感到困惑。如下圖：
地址40003中，確實是昌暉儀表希望的328的數值，可是地址40004中竟然也是這個值。在地址表中，我們可以看到該數據應該是一個32位雙字的長整型數據才對，所以如果對于數值328來說，40004中的數值應該為0才對。即使考慮了高低字交換，高低字節交換，有無符號數,地址偏移1位等因素，這個數值依然不對。昌暉儀表又進行了多次測試，發現40003和40004的數值始終相等。然后，昌暉儀表習慣性的想先測試1個數，看看能不能讀上來，于是就在上圖的配置中，把數據長度從14改為了1，奇怪的是，這時40003的數值竟然讀不上來了。難道問題和數據長度有關？
于是，昌暉儀表工程師又仔細看了下該廠家流量積算儀手冊，有了點不太確定的發現(直到現在仍不太確定)。在上面的協議中，有這么一句：
◆讀當前數據
計算機→FC6000(4-8bytes)：$，03H，XXXX，CRC
這里的4-8字節莫非是指我們一次只能讀取4-8字節的數據？仔細查看該表的數據，我們看到所有的數據都是4字節長的。所以，昌暉儀表就在ModScan中，把數據長度改為2，經過修改后，表里的7個數據都可以讀到且正常。最后，我們在PLC中做了如下配置，分7次讀取這7個數據，結果正常。
這里，昌暉儀表不能說儀表有問題，只能說其手冊寫得應該更明確些。
3、流量積算儀MODBUS通訊：人家是標準Modbus RTU協議……只不過校驗是反的
這塊流量積算儀的問題更直接，當使用ModScan按其手冊發送內容讀取數據時，儀表沒有數據回復。但是如果使用流量積算儀廠家自帶的一個小軟件測試儀表的通信，數據是完全正常的。由于和廠家軟件測試使用的物理鏈路完全相同，所以應該還是報文協議上出現了一些問題。這就需要我們仔細的閱讀廠家手冊。
經過反復研讀廠家的手冊，終于昌暉儀表發現了一個之前很少遇到的情況，下圖是通信協議的一部分：
6、通訊命令：
功能代碼03-用來讀取顯示數據
發送01；地址回應01；地址
03；功能碼03；功能碼
00；寄存器地址高04；；字節個數
01；寄存器地址低(顯示地址)80；數據1
00；寄存器個數高04；數據2
04；寄存器個數低80；數據3
CRCH；CRC校驗碼高80；數據4
CRCL；CRC校驗碼低CRCH；CRC校驗碼高
CRCL；CRC校驗碼低
說明：地址=儀表號；寄存器地址=顯示項目編號；回應字節個數=(發送)寄存器個數低(1-63)
在標準Modbus協議中，報文的最后兩個字節為CRC校驗字節，在正常情況下，一般是先發CRC的低字節，然后再發CRC的高字節。如果CRC校驗不對，設備可以對報文不做應答。在一般的PLC或是組態軟件的標準Modbus塊或者驅動中，昌暉儀表未曾見過可以修改CRC高低字節的設置，故在此情況下，我們直接用ModScan或者PLC里預制的標準Modbus塊是無法和該儀表進行通信的。所以，在后續處理和這塊表的通信時，昌暉儀表使用了自由協議的方式，用PLC的TX功能塊直接發送報文，然后對儀表回復的報文用RX功能塊接收后進行解析。
4、其他
某些流量積算儀是有Modbus RTU和ASCII的選項的。但是昌暉儀表在測試中，發現有的流量積算儀稱RTU為”寄存器模式”，ASCII為”字符模式”，這在配置流量積算儀時需要注意。
在前文中也提到過，流量積算儀中的很多數據往往是32位的雙整型數據或IEEE754單精度浮點型數據。既然是32位數據，在不同的PLC或者設備中，其高低字或高低字節的存放順序各有不同。所以，如果通信可以通上但數據讀上來是亂碼，大多數情況下，對于32位雙整型數據，可以交換其高低字；對于32位單精度浮點數，由于其有1234,2143,3412,4321這4中可能，可以先交換高低字，如果不正確后可以再對高低字節交換進行測試。在PLC中，除了用Move指令進行交換外，還可以使用循環移位指令對單字循環左移/右移8位以交換高低字節，或者對雙字循環左移/右移16位以交換高低字。在一些流量積算儀中，也提供了此種功能，已方便用戶使用。
同時需要注意的是，某些流量積算儀的浮點數未必是標準的IEEE754格式，可能是其自定義的數值格式，如下圖。這時就需要我們根據其手冊，在PLC或上位機中編制對應的轉換程序。
作者：張偉寧
推薦閱讀
數顯表與PLC串口通信調試的步驟和方法
昌暉數顯儀表與組態王工控軟件通信組態實例
