簡介工業(yè)上位機(jī)開發(fā)中三菱PLC是最常見的控制設(shè)備之一。理解其通訊協(xié)議是打通上層應(yīng)用與現(xiàn)場設(shè)備的關(guān)鍵。三菱PLC根據(jù)系列不同分別支持FX編程口與MC 3E/4E等協(xié)議物理鏈路則分為串口和以太網(wǎng)。通信幀的本質(zhì)是地址編碼、長度與校驗(yàn)三者的正確組合任何一項(xiàng)偏差都會(huì)導(dǎo)致NAK或無響應(yīng)。掌握這些基礎(chǔ)后開發(fā)者可以在Visual Studio 2019中用C與Qt快速封裝通訊類實(shí)現(xiàn)D/M/X/Y寄存器的可靠讀寫。這類能力適用于產(chǎn)線數(shù)據(jù)采集、設(shè)備監(jiān)控等典型工控場景配合源碼的輪詢調(diào)度與異常重試機(jī)制能有效縮短上位機(jī)調(diào)試周期避免在現(xiàn)場反復(fù)踩坑。1. 用 C 在 VS2019 里寫 QT 上位機(jī)調(diào)三菱 PLC這套通訊源碼就是干這個(gè)的手里同時(shí)壓著 QT 界面、C 業(yè)務(wù)邏輯和一臺(tái)三菱 PLCVisual Studio 2019 里來回切窗口通訊卻一封幀都發(fā)不出去——這種狀態(tài)我太熟悉了。這套源碼解決的正是“ QT VS2019 C 與三菱 PLC 通訊”這個(gè)組合里的最后一公里不糾結(jié)界面先把 FX 編程口和 MC 3E 幀兩種協(xié)議封裝成能直接調(diào)用的類串口、以太網(wǎng)兩條鏈路都給你鋪好。適合剛接手工控上位機(jī)的新手也適合不想再翻三菱協(xié)議文檔、只想快速驗(yàn)證讀寫功能的熟手。拿到手先跑通 Demo再替換成自己的業(yè)務(wù)邏輯比從空工程一點(diǎn)點(diǎn)焊要省太多事。2. 協(xié)議選型和通訊鏈路FX 編程口、MC 3E 幀串口還是以太網(wǎng)2.1 三菱 PLC 常見通訊方式FX 編程口、MC 3E/4E、A-1E 怎么選三菱 PLC 不是一個(gè)協(xié)議打天下。FX 系列走自家編程口協(xié)議Q/L/iQ-R 系列走 MC 協(xié)議MC 協(xié)議本身又分以太網(wǎng) 3E 幀、4E 幀和串口 A-1E 幀。選錯(cuò)協(xié)議后面的幀構(gòu)造全是白費(fèi)。先看這張對(duì)照表基本能定方向通訊方式物理層典型命令適用系列特點(diǎn)FX 編程口RS-422/48530H 讀、31H 寫FX3U / FX3G接線簡單默認(rèn) 9600 8 Even 1單幀點(diǎn)數(shù)受限MC 3E 幀TCP / UDP0401 批量讀、1401 批量寫Q / L / iQ-R二進(jìn)制幀緊湊以太網(wǎng)速率高Qna-3E 最經(jīng)典MC 4E 幀TCP / UDP在 3E 基礎(chǔ)上帶 CPU 編號(hào)FX5U / iQ-R多 CPU 尋址FX5U 默認(rèn)走這個(gè)變體MC A-1E 幀串口 RS-232/422ASCII 幀Q 系列串口模塊報(bào)文可讀性好但效率低老設(shè)備還在用我的選擇標(biāo)準(zhǔn)很樸素FX3U 這種小 PLC項(xiàng)目里只要讀寫 D 寄存器、M 位、X/Y 狀態(tài)直接上 FX 編程口一條 USB-RS422 線就夠Q 系列或 iQ-R 這種走以太網(wǎng)的用 MC 3E 幀F(xiàn)X5U 則要留意 4E 幀——很多人在 FX5U 上套 3E 幀死活連不上其實(shí)就是少了兩字節(jié) CPU 編號(hào)。A-1E 幀現(xiàn)在只在改造老產(chǎn)線時(shí)遇到新項(xiàng)目基本不碰。2.2 這套源碼為什么要做串口 以太網(wǎng)雙通道仔細(xì)看這份源碼的類結(jié)構(gòu)你會(huì)發(fā)現(xiàn)它沒有把寶押在一條鏈路上。抽象基類只管收發(fā)字節(jié)流底下掛了兩個(gè)實(shí)現(xiàn)一個(gè)用 QSerialPort 走 FX 編程口一個(gè)用 QTcpSocket 走 MC 3E 幀。界面層通過同一個(gè)接口調(diào)讀寫底層切協(xié)議上層一行不用改。這樣設(shè)計(jì)不是拍腦袋。實(shí)際產(chǎn)線里以太網(wǎng)口經(jīng)常被交換機(jī)、防火墻、IP 沖突卡住現(xiàn)場工程師最后掏出老式 USB-RS422 線救急是常事。雙通道意味著你在辦公室用網(wǎng)口調(diào)試到了現(xiàn)場發(fā)現(xiàn)網(wǎng)線沒布切換串口只是改一行配置的事。邊界條件也說清楚串口是一主一從的令牌式通訊別想在一條 RS-485 總線上同時(shí)輪詢好幾臺(tái) FX 系列還能保證實(shí)時(shí)性重載嚴(yán)重時(shí)會(huì)偶發(fā)超時(shí)TCP 鏈路倒是可以按站號(hào)區(qū)分多臺(tái) PLC每臺(tái)連接獨(dú)立端口輪詢各自維護(hù)。源碼里默認(rèn)網(wǎng)口端口是 6001三菱 PLC 以太網(wǎng)模塊常見端口可改。2.3 幀格式的本質(zhì)地址編碼、長度、校驗(yàn)三件事決定能不能通為什么三菱協(xié)議比 Modbus 難上手Modbus 的寄存器地址就是一個(gè) 16 位編號(hào)三菱偏要搞“軟元件代碼 軟元件編號(hào)”的組合編址。比如 D100 在 MC 協(xié)議里是軟元件代碼 0x00A8、偏移地址 0x0064到了 FX 編程口D0 的通訊地址又變成 0x1000。同一個(gè) D 寄存器兩種協(xié)議地址起點(diǎn)完全不同新手常在這里翻車。所以別把協(xié)議當(dāng)黑匣子背。通訊成功的本質(zhì)就三件事地址編碼對(duì)得上、幀長度字段對(duì)得上、校驗(yàn)和對(duì)得上。地址錯(cuò)了PLC 回結(jié)束碼錯(cuò)誤長度錯(cuò)了整個(gè)幀解析錯(cuò)位校驗(yàn)錯(cuò)了直接 NAK。這套源碼把三件事都封裝在幀構(gòu)造函數(shù)里你要做的只是傳入軟元件號(hào)和數(shù)量它幫你算地址、算長度、算校驗(yàn)。3. VS2019 QT 集成裝插件、跑通第一個(gè)串口 Demo、把 DLL 送到真機(jī)3.1 工具鏈三件套Qt 5.15.2、VS2019 v142、Qt VS Tools先把環(huán)境固定下來。我一般固定用 Qt 5.15.2 MSVC2019 64 位、Visual Studio 2019 的 v142 工具集、Qt VS Tools 擴(kuò)展。這套組合對(duì)應(yīng)關(guān)系最穩(wěn)網(wǎng)上報(bào)錯(cuò)也最少。安裝順序先裝 VS2019確認(rèn)“使用 C 的桌面開發(fā)”工作負(fù)載勾上再裝 Qt 5.15.2裝的時(shí)候勾上 MSVC 2019 64-bit最后在 VS 里打開“擴(kuò)展 → 管理擴(kuò)展”搜索 Qt Visual Studio Tools 安裝。裝完在“擴(kuò)展 → Qt VS Tools → Qt Versions”里把 msvc2019_64 的路徑指進(jìn)去。新建工程不要選錯(cuò)模板。源碼里是 Qt Console 起手把 widget 界面后加或者直接選 Qt Widgets Application。工程文件里要顯式聲明串口和網(wǎng)絡(luò)模塊QT core gui serialport network greaterThan(QT_MAJOR_VERSION, 4): QT widgets CONFIG c17 DEFINES QT_DEPRECATED_WARNINGSserialport對(duì)應(yīng) QSerialPortnetwork對(duì)應(yīng) QTcpSocket 和 QUdpSocket。漏掉其中一個(gè)模塊編譯直接報(bào)“未定義引用”或頭文件找不到。CONFIG c17是讓源碼里的結(jié)構(gòu)化綁定、lambda 捕獲這些語法能過 v142 編譯器。3.2 無插件備選CMake 打開文件夾適合不想被 IDE 綁死的團(tuán)隊(duì)如果你的團(tuán)隊(duì)不用 Qt VS Tools或者 VS 版本和 Qt 庫工具集對(duì)不上可以走 CMake 路線。VS2019 原生支持“打開文件夾”模式CMakeLists 寫對(duì)就能跑cmake_minimum_required(VERSION 3.16) project(plc_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt5 5.15 REQUIRED COMPONENTS Widgets SerialPort Network) add_executable(plc_demo main.cpp PlcClient.cpp PlcClient.h ) target_link_libraries(plc_demo Qt5::Widgets Qt5::SerialPort Qt5::Network )關(guān)鍵在find_package能不能找到 Qt。如果 Qt 裝在 D 盤要在 CMakeSettings.json 或環(huán)境變量里加CMAKE_PREFIX_PATHD:/Qt/5.15.2/msvc2019_64否則會(huì)報(bào)“找不到 Qt5Config.cmake”。這條路徑是 Qt 庫的根目錄不是 src 目錄很多新手在這寫錯(cuò)。CMake 路線的優(yōu)點(diǎn)是工程文件可提交到 Git同事拉下來不用配插件路徑缺點(diǎn)是首次配置慢且 Qt 版本切換需要手動(dòng)改路徑。二選一即可源碼兩者都支持。3.3 最小串口驗(yàn)證程序和部署時(shí)缺 DLL 的坑環(huán)境通了先別急著跑完整界面寫個(gè)最小程序驗(yàn)證串口物理鏈路。FX 編程口默認(rèn)參數(shù)是 9600、8 數(shù)據(jù)位、偶校驗(yàn)、1 停止位注意是 Even不是 NoParityQSerialPort ser; ser.setPortName(COM3); ser.setBaudRate(QSerialPort::BaudRate9600); ser.setDataBits(QSerialPort::Data8); ser.setParity(QSerialPort::EvenParity); // FX編程口默認(rèn)偶校驗(yàn) ser.setStopBits(QSerialPort::OneStop); ser.setFlowControl(QSerialPort::NoFlowControl); if (!ser.open(QIODevice::ReadWrite)) { qWarning() ser.errorString(); return false; } QObject::connect(ser, QSerialPort::readyRead, []() { qDebug() ser.readAll().toHex(); }); ser.write(frame); ser.waitForBytesWritten(500);waitForBytesWritten只保證數(shù)據(jù)進(jìn)了驅(qū)動(dòng)緩沖區(qū)不代表 PLC 已經(jīng)收到。真正判斷成功要看readyRead回調(diào)里有沒有回幀。掉進(jìn) NoParity 的坑現(xiàn)象是寫入后 PLC 完全無視因?yàn)樾ｒ?yàn)位對(duì)不上串口驅(qū)動(dòng)層面就已經(jīng)把幀丟了。把程序拷到工控機(jī)之前一定要在開發(fā)機(jī) Release 目錄跑一遍windeployqtwindeployqt --release --no-translations .\plc_demo.exe它會(huì)自動(dòng)拷入 Qt 的 platforms 插件、串口插件和依賴 DLL。最典型的部署事故是exe 拷過去了雙擊閃退事件查看器里報(bào)“無法加載平臺(tái)插件”其實(shí)就是platforms/qwindows.dll沒帶。還有 MSVC 運(yùn)行庫目標(biāo)機(jī)器沒裝 vc_redist 也會(huì)靜默失敗。4. 核心實(shí)現(xiàn)拆解幀結(jié)構(gòu)、軟元件地址映射、校驗(yàn)和與輪詢線程4.1 通訊類架構(gòu)一個(gè)接口、兩個(gè)協(xié)議實(shí)現(xiàn)源碼里最值得抄的不是某一段幀代碼而是這套分層IPlcClient (抽象接口) ├── FxSerialClient // FX編程口QSerialPort ├── Mc3eTcpClient // MC 3E幀QTcpSocket └── Mc4eTcpClient // MC 4E幀F(xiàn)X5U變體接口只暴露readD(addr, count)、writeD(addr, values)、readM(addr, count)之類的業(yè)務(wù)方法。界面層不關(guān)心底層是串口還是網(wǎng)口切換協(xié)議就是換一個(gè)對(duì)象實(shí)例。這也是我自己做上位機(jī)時(shí)的固定習(xí)慣先把協(xié)議封裝從界面里剝出去后面加功能才不用動(dòng) UI 代碼。4.2 FX 編程口讀寫命令碼 30H/31HSTX/ETX 與兩位校驗(yàn)和FX 編程口幀結(jié)構(gòu)不長但非?？简?yàn)細(xì)節(jié)點(diǎn)。讀命令幀格式是STX(0x02) 命令碼0(0x30) 首位地址(4位ASCII) 讀取點(diǎn)數(shù)(2位ASCII) ETX(0x03) 校驗(yàn)和(2位ASCII)注意地址和數(shù)量都是 ASCII 十六進(jìn)制字符不是二進(jìn)制數(shù)。D0 的協(xié)議地址是 0x1000則地址字段是1000。點(diǎn)數(shù) 2 寫成02。讀 8 個(gè) D 寄存器代碼如下QByteArray buildFxReadFrame(quint16 addr, quint16 count) { QByteArray body; body.append(char(0x30)); // 讀命令 0 body.append(QString::number(addr, 16) .rightJustified(4, 0) .toLatin1().toUpper()); // 地址4位ASCII body.append(QString::number(count, 16) .rightJustified(2, 0) .toLatin1().toUpper()); // 點(diǎn)數(shù)2位ASCII body.append(char(0x03)); // ETX quint8 sum 0; for (int i 0; i body.size(); i) { sum static_castquint8(body.at(i)); // 校驗(yàn)CMD到ETX累加 } QByteArray frame; frame.append(char(0x02)); // STX frame.append(body); frame.append(QString::number(sum, 16) .rightJustified(2, 0) .toLatin1().toUpper()); return frame; }邏輯說明校驗(yàn)和是所有有效字節(jié) ASCII 碼累加的低 8 位轉(zhuǎn)成兩位大寫十六進(jìn)制。最容易錯(cuò)的點(diǎn)是校驗(yàn)范圍和是否轉(zhuǎn)大寫沒有轉(zhuǎn)大寫PLC 回 NAK把 STX 也算進(jìn)去同樣 NAK。所以我把 STX 放在 body 外面累加從源頭避免這個(gè)坑。地址參數(shù)addr是協(xié)議地址不是 D 寄存器號(hào)。D0 對(duì)應(yīng) 0x1000D100 對(duì)應(yīng) 0x1064。單幀讀取點(diǎn)數(shù)受協(xié)議限制FX3U 建議單次不超過 64 點(diǎn)超過就拆幀。響應(yīng)數(shù)據(jù)是每個(gè) D 值返回 4 個(gè) ASCII 字符低字節(jié)在前解析時(shí)按 4 字符一組還原 16 位值。寫命令和讀命令結(jié)構(gòu)幾乎一樣只是命令碼變10x31在 ETX 前把數(shù)據(jù)按“先低字節(jié)后高字節(jié)、每個(gè)字節(jié)拆兩個(gè) ASCII 字符”塞進(jìn)去。注意寫 D 值是 16 位32 位數(shù)據(jù)要連續(xù)寫兩個(gè) D低 D 在前。4.3 MC 3E 幀構(gòu)造Little Endian 字節(jié)序與軟元件代碼MC 3E 幀比 FX 編程口復(fù)雜在頭部長且全部走二進(jìn)制小端序。以 Q 系列批量讀 D 區(qū)為例最少字節(jié)的請(qǐng)求幀長這樣副頭 0x5000 網(wǎng)絡(luò)號(hào) 00 PC號(hào) FF IO編號(hào) 03FF 站號(hào) 00 請(qǐng)求數(shù)據(jù)長度 監(jiān)視定時(shí)器 指令 0401 子指令 0000 軟元件代碼 00A8 軟元件地址(3字節(jié)) 點(diǎn)數(shù)代碼實(shí)現(xiàn)如下QByteArray buildMc3eRead(quint16 deviceCode, quint32 offset, quint16 points) { QByteArray req; req.append(char(0x50)); req.append(char(0x00)); // 副頭 0x5000 req.append(char(0x00)); // 網(wǎng)絡(luò)號(hào) req.append(char(0xFF)); // PC號(hào) req.append(char(0xFF)); req.append(char(0x03)); // IO編號(hào) 03FF, 小端 req.append(char(0x00)); // 站號(hào) req.append(char(0x00)); req.append(char(0x00)); // 請(qǐng)求長度, 稍后回填 req.append(char(0x10)); req.append(char(0x00)); // 監(jiān)視定時(shí)器 req.append(char(0x01)); req.append(char(0x04)); // 批量讀 0401, 小端 req.append(char(0x00)); req.append(char(0x00)); // 子指令, 字訪問 req.append(char(deviceCode 0xFF)); // 軟元件代碼低字節(jié) req.append(char((deviceCode 8) 0xFF)); // 軟元件代碼高字節(jié) req.append(char(offset 0xFF)); // 地址第1字節(jié) req.append(char((offset 8) 0xFF)); // 地址第2字節(jié) req.append(char((offset 16) 0xFF)); // 地址第3字節(jié) req.append(char(points 0xFF)); // 點(diǎn)數(shù)低字節(jié) req.append(char((points 8) 0xFF)); // 點(diǎn)數(shù)高字節(jié) quint16 len req.size() - 9; // 長度從監(jiān)視定時(shí)器開始算 req[7] static_castchar(len 0xFF); req[8] static_castchar((len 8) 0xFF); return req; }邏輯說明deviceCode是軟元件代碼D 區(qū)是 0x00A8M 區(qū)是 0x0090X 區(qū)是 0x009CY 區(qū)是 0x009D。offset是軟元件地址D0 就是 0D100 就是 0x64。整個(gè)幀從頭到尾都是小端一眼就能看到大量“先低后高”的字節(jié)排布。長度字段的回填是我踩過最多次的地方。不同版本的協(xié)議文檔對(duì)“請(qǐng)求數(shù)據(jù)長度”的定義有差異有的從監(jiān)視定時(shí)器開始算有的從指令開始算。源碼統(tǒng)一采用“從監(jiān)視定時(shí)器到幀尾的字節(jié)數(shù)”實(shí)測能通過 Q 系列通訊測試。如果你拿到的協(xié)議文檔算出的長度和這里不一致不要糾結(jié)以實(shí)際回顯的結(jié)束代碼為準(zhǔn)調(diào)。響應(yīng)幀的結(jié)構(gòu)是副頭、網(wǎng)絡(luò)號(hào)、PC 號(hào)、IO、站號(hào)、長度、結(jié)束代碼再跟數(shù)據(jù)。結(jié)束代碼 0x0000 代表正常0xC051 是范圍外地址0xC052 是指定點(diǎn)數(shù)超限。解析響應(yīng)時(shí)先檢查結(jié)束代碼再按點(diǎn)數(shù)解析數(shù)據(jù)別一上來就拿數(shù)據(jù)算。MC 4E 幀和 3E 幀的區(qū)別是在請(qǐng)求里多了一個(gè) 2 字節(jié)的 CPU 編號(hào)放在監(jiān)視定時(shí)器之后、指令之前。FX5U 和 iQ-R 多 CPU 環(huán)境下必須帶單 CPU 時(shí)填 0x0000 也能通。4.4 軟元件地址映射表D/M/X/Y 在兩種協(xié)議里的不同起點(diǎn)兩種協(xié)議最大的混淆點(diǎn)就是地址起點(diǎn)。我整理了一張常用映射表源碼的 SoftElementTable 里也是同一份軟元件類型MC 3E 代碼FX 編程口協(xié)議地址說明D字0x00A80x1000 D號(hào)16位數(shù)據(jù)寄存器32位用連續(xù)兩個(gè)DM位0x00900x0100 M號(hào)M8000特殊繼電器同樣按此編址X位0x009C0x03E0 八進(jìn)制地址輸入注意八進(jìn)制編號(hào)Y位0x009D0x0400 八進(jìn)制地址輸出注意八進(jìn)制編號(hào)X 和 Y 的編號(hào)是八進(jìn)制的X0 到 X7 是 0x03E0 到 0x03E7X10 是 0x03E8中間跳過 8 和 9。很多新手用十進(jìn)制遞增算地址結(jié)果讀寫的是別的點(diǎn)排查半天才發(fā)現(xiàn)是進(jìn)制問題。D 區(qū)相對(duì)規(guī)矩D0 0x1000 這個(gè)錨點(diǎn)要死記MC 協(xié)議里 D0 卻是 0x000000不要混。4.5 輪詢調(diào)度QTimer 異步隊(duì)列、超時(shí)重試和斷線判定上位機(jī)讀 PLC 最常見的設(shè)計(jì)錯(cuò)誤是發(fā)完請(qǐng)求后用while死等響應(yīng)把 UI 線程堵死。正確做法是異步隊(duì)列QTimer 定時(shí)發(fā)請(qǐng)求等響應(yīng)的窗口期用單次定時(shí)器做超時(shí)判斷超時(shí)丟幀但不阻塞界面。class PlcPoller : public QObject { Q_OBJECT public: explicit PlcPoller(IPlcClient *client, QObject *parent nullptr) : QObject(parent), io(client) { timer.setInterval(100); connect(timer, QTimer::timeout, this, PlcPoller::tick); connect(io, IPlcClient::responseReady, this, PlcPoller::onResponse); } private slots: void tick() { if (busy) return; if (retry 3) { emit linkLost(); // 連續(xù)超時(shí), 判定斷線 return; } busy true; io-send(buildMc3eRead(0x00A8, 0x0000, 8)); QTimer::singleShot(500, this, [this]() { if (busy) { retry; busy false; } // 500ms無響應(yīng), 丟幀重試 }); } void onResponse(const QByteArray resp) { if (!busy) return; retry 0; busy false; emit dataReady(parseDWords(resp)); } private: IPlcClient *io; QTimer timer; bool busy false; int retry 0; };邏輯說明這個(gè)狀態(tài)機(jī)只有兩個(gè)狀態(tài)空閑和等待響應(yīng)。busy防止上一次還沒回應(yīng)就發(fā)下一次retry超過 3 次就通知界面層顯示斷線同時(shí)停止發(fā)請(qǐng)求等 PLC 側(cè)鏈路恢復(fù)后再自動(dòng)重連。這種設(shè)計(jì)下線纜松了、PLC 停電界面不會(huì)卡死只會(huì)彈狀態(tài)。參數(shù)調(diào)優(yōu)100ms 輪詢適合人機(jī)界面顯示、數(shù)據(jù)采集這類場景運(yùn)動(dòng)控制或高速配方切換建議把間隔壓到 20ms并且把 poller 放到獨(dú)立線程。注意 QTimer 的最小有效間隔是系統(tǒng)定時(shí)器分辨率Windows 下大約是 15.6ms所以別寫 1ms 這種虛參數(shù)。5. 避坑與排查串口沒反應(yīng)、NAK、數(shù)據(jù)錯(cuò)位5 個(gè)高頻坑5.1 串口能打開但 PLC 無響應(yīng)多半是偶校驗(yàn)或 RS-485 方向控制現(xiàn)象COM 口能打開TX 燈在閃但 PLC 端毫無動(dòng)作readyRead一直不觸發(fā)。原因兩種情況最常見。一是 FX 編程口默認(rèn)是偶校驗(yàn)代碼里卻配了 NoParity這一項(xiàng)不對(duì)底層串口就把幀過濾了二是用的 RS-485 轉(zhuǎn)接器沒有自動(dòng)方向控制數(shù)據(jù)發(fā)出去后發(fā)送使能沒拉回接收狀態(tài)PLC 的回應(yīng)發(fā)不出來。解決先把串口參數(shù)改成 9600、8、Even、1寫死在初始化代碼里并標(biāo)注注釋方向控制問題買帶“自動(dòng)收發(fā)切換”的 USB-RS422 轉(zhuǎn)換器或者軟件層面在write之后QThread::msleep(2)讓發(fā)送使能穩(wěn)定切回接收再開始讀。5.2 返回 NAK 15H校驗(yàn)和算錯(cuò)而且錯(cuò)得很隱蔽現(xiàn)象串口收發(fā)都正常發(fā)送讀命令后立刻收到 0x15NAK或者收到幀頭但數(shù)據(jù)全是亂碼。原因FX 編程口的校驗(yàn)和是從命令碼到 ETX 結(jié)束符之間所有字節(jié) ASCII 碼的累加和低 8 位轉(zhuǎn)成兩個(gè)大寫十六進(jìn)制字符。有人把 STX 納入了校驗(yàn)范圍有人忘了轉(zhuǎn)大寫有人用 Unicode 字符串求和導(dǎo)致每個(gè)字符多算一個(gè) 0x00。解決嚴(yán)格按代碼里的sum static_castquint8(body.at(i))方式累加。調(diào)試時(shí)把這個(gè)校驗(yàn)和打印出來和 PLC 調(diào)試軟件的監(jiān)視窗對(duì)比一眼就能看出差異。5.3 數(shù)據(jù)高低字節(jié)錯(cuò)位D 值讀回來變成 0x4321現(xiàn)象寫入 D0 0x1234讀回來顯示 0x3412或者數(shù)值對(duì)但翻倍、變小。原因三菱協(xié)議全部是小端傳輸數(shù)據(jù)區(qū)先到的是低字節(jié)。界面層用qFromBigEndian解析或者從 QByteArray 取數(shù)時(shí)直接按大端索引就會(huì)錯(cuò)位。解決統(tǒng)一用qFromLittleEndianquint16解析每個(gè) D 值不要手動(dòng)(buf[0] 8) | buf[1]。如果你做的是跨平臺(tái)代碼還要注意不同編譯器對(duì)char符號(hào)性的處理取字節(jié)前一律static_castquint8。5.4 輪詢 10ms CPU 吃滿、UI 卡死現(xiàn)象程序一啟動(dòng)就有一個(gè)核跑滿界面拖拽明顯掉幀最小化再恢復(fù)要等好幾秒。原因輪詢間隔設(shè)成 10ms且讀寫邏輯放在主線程里同步執(zhí)行。Windows 下 QTimer 實(shí)際觸發(fā)頻率受系統(tǒng)計(jì)時(shí)器限制密集的短周期同步 I/O 會(huì)把 UI 事件循環(huán)餓死。解決把輪詢類移到 QThread 子線程界面只通過信號(hào)槽接收最終數(shù)據(jù)輪詢間隔按場景設(shè)置界面顯示類 100ms 足夠高速采集最低也建議 20ms。不要為了“實(shí)時(shí)性”盲調(diào) 1ms三菱 PLC 的響應(yīng)周期本身就在 10ms 量級(jí)發(fā)太快只會(huì)把總線打滿。5.5 VS2019 報(bào) MSB8020 / 找不到 Qt 頭文件現(xiàn)象解決方案資源管理器里工程有黃色嘆號(hào)編譯報(bào)“MSB8020 找不到 v142 生成工具”或者#include QSerialPort直接提示找不到。原因MSB8020 是 Qt 庫用 v141 編譯而你工程用 v142或反之找不到頭文件是 Qt VS Tools 的 Qt Version 路徑配錯(cuò)常見是把路徑指到了 Qt 的安裝目錄而不是 msvc2019_64 庫目錄。解決在“項(xiàng)目屬性 → 常規(guī) → 平臺(tái)工具集”里明確選 Visual Studio 2019 (v142)和 Qt 庫一致再到 Qt VS Tools → Qt Versions 里檢查路徑必須是D:\Qt\5.15.2\msvc2019_64而不是D:\Qt。改完清一遍解決方案再重新生成不要只按增量編譯。6. 不連 PLC 先驗(yàn)證幀Python 回環(huán)腳本和三件套檢查法6.1 回環(huán)腳本先驗(yàn)證幀PLC 不在手邊或者現(xiàn)場設(shè)備在別人產(chǎn)線里跑著沒法反復(fù)試。這種時(shí)候我用一個(gè) Python 回環(huán)腳本在本地模擬 PLC 的 TCP 響應(yīng)先用它驗(yàn)證客戶端發(fā)幀和解析邏輯是不是自洽import socket, binascii srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((0.0.0.0, 6000)) # 與上位機(jī) PLC 端口保持一致 srv.listen(1) conn, _ srv.accept() while True: data conn.recv(256) if not data: break print(recv:, binascii.hexlify(data, )) # 偽造一個(gè)結(jié)束碼0000、帶8個(gè)D值的響應(yīng) body bytes.fromhex( 500000ff0300000c000000010 0000000010203040506070809 ) conn.send(body)邏輯說明腳本不做協(xié)議解析只把收到的幀按十六進(jìn)制打印出來再返回一個(gè)結(jié)構(gòu)合法的 3E 響應(yīng)。這個(gè)過程用來驗(yàn)證三件事客戶端有沒有發(fā)出完整幀、長度字段是否穩(wěn)定、響應(yīng)解析會(huì)不會(huì)崩。如果客戶端本身幀構(gòu)造錯(cuò)了回環(huán)腳本打印出來的十六進(jìn)制一眼就能看出頭部偏位。6.2 真機(jī)三件套檢查回環(huán)腳本通過后再上真機(jī)。我每次連真機(jī)固定走三件套檢查第一確認(rèn) PLC 的 IP 和端口能 ping 通telnet 端口能建立連接第二確認(rèn) PLC 側(cè)通訊參數(shù)里的幀類型是 3E 幀還是 4E 幀Q 系列選 Qna-3EFX5U 選 4E選錯(cuò)連握手都過不去第三確認(rèn)軟元件地址沒超范圍D 區(qū)范圍外的地址會(huì)回 C051 結(jié)束碼?；丨h(huán)腳本還有個(gè)額外好處可以拿來做回歸測試。改了解析代碼先跑一遍回環(huán)再連真機(jī)能把“協(xié)議問題”和“現(xiàn)場問題”隔離開。從那以后我每次接到新 PLC 型號(hào)都強(qiáng)制先做一遍幀回環(huán)驗(yàn)證再上真機(jī)調(diào)參數(shù)這套流程幫我省掉過太多現(xiàn)場翻車的狼狽。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取