前面我們已經分析了Modbus RTU的更新設計和具體實現（如果不清楚可查看前一篇文章）。其實Modbus ASCII與Modbus RTU都是基于串行鏈路實現的，所以有很多的共同點，基于此，這篇文章我們只討論與Modbus RTU所不同的部分。

1、更新設計

關于原來的協議棧在Modbus ASCII主站應用時所存在的局限性與Modbus RTU也是一樣的，所以我們不分析它的不足，只討論更新設計。我們將主站及其所訪問的從站定義為通用的對象，而當我們在具體應用中使用時，再將其特例化為特定的主站和從站對象。

首先我們來考慮主站，原則上我們規劃的每一個主站對象對應我們設備上的一個端口，這里所說端口就是指串口。那么在同一端口下，也就是在一個特定主站下，我們可以定義多個地址不同的從站。而在不同的端口上可以具有地址相同的從站。如下圖所示：

從上圖中我們可以發現，我們的目的就是讓協議棧支持，多主站和多從站，并且在不同主站下，從站的地址重復不受影響。從上圖看視乎一個主站對象可以同時管理254個從站對象，事實上還要受到帶載能力的影響。

接下來我們還需要考慮從站對象。主站對從站的操作無非兩類：讀從站信息和寫從站信息。對于讀從站信息來說，主站需要發送請求命令，等待從站返回響應信息，然后主站解析收到的信息并更新對應的參數值。有兩點需要我們考慮，第一返回的響應消息是沒有對應的寄存器地址的，所以要想在解析的時候定位寄存器就必須知道發送的命令，為了便于分辨我們將命令存放在從站對象中。第二在解析響應時，如果兩條命令的響應類似是沒法分辨的，所以我們還需要記住上一條命令是什么。也存儲于從站對象中。

而對于寫從站操作，無論寫的要求來自于哪里，對于協議棧來說肯定是其它的數據處理進程發過來的，所接到要求后我們需要記錄是哪一個主站管理的哪一個從站的哪些參數。對于主站我們不需要分辨，因為每個主站都是獨立的處理進程，但是對于從站和參數我們就需要分辨。每一個主站可以帶的站地址為0到255，但0和255已有定義，所以實際是1到254個。所以我們使用一個256位的變量，每位對應站號來標志其是否有需要寫的請求。記錄于主站，具體如下：

事實上，我們不可能會用到256個標志位，因為Modbus ASCII本身就是為簡單應用而設定的。我們使用256個標志位，主要是考慮到站地址的取值范圍，方便軟件操作而定的。還有每個從站的寫參數請求標志，我們將其存儲于各個從站對象，因為不同的從站可能有很大區別，存儲于各個從站更加靈活方便。

2、編碼實現

我們已經設計了我們的更新，接下來我們就根據這一設計來實現它。我們主要從以下幾個方面來操作：第一，實現主站對象類型和從站對象類型；第二，主站對象的實例化及從站對象的實例化；第三，讀從站的主站操作過程；第四，寫從站的主站操作過程。接下來我們將一一描述之。

2.1、定義對象類型

與在Modbus RTU一樣，在Modbus ASCII協議棧的封裝中，我們也需要定義主站對象和從站對象，自然也免不了要定義這兩種類型。

首先我們來定義本地主站的類型，其成員包括：一個uint32_t的寫從站標志數組；從站數量字段；從站順序字段；本主站過管理的從站列表；4個數據更新函數指針。具體定義如下：

/* 定義本地ASCII主站對象類型 */ typedef struct LocalASCIIMasterType{uint32_t flagWriteSlave[8];?? //寫一個站控制標志位，最多256個站，與站地址對應。uint16_t slaveNumber;???????? //從站列表中從站的數量uint16_t readOrder;?????????? //當前從站在從站列表中的位置ASCIIAccessedSlaveType *pSlave;???????? //從站列表UpdateCoilStatusType pUpdateCoilStatus;?????? //更新線圈量函數UpdateInputStatusType pUpdateInputStatus;???? //更新輸入狀態量函數UpdateHoldingRegisterType pUpdateHoldingRegister;???? //更新保持寄存器量函數UpdateInputResgisterType pUpdateInputResgister;?????? //更新輸入寄存器量函數 }ASCIILocalMasterType;

關于主站對象類型，在前面的更新設計中已經講的很清楚了，只有兩個字段需要說明一下。第一，從站列表是用來記錄本主站所管理的從站對象。第二，readOrder字段表示為當前訪問從站在列表中的位置，而slaveNumber是從站對象的數量，即列表的長度。具體如下圖所示：

還需要定義從站對象，此從站對象只是便于主站而用于表示真是的從站。主站的從站列表中就是此對象。具體結構如下：

/* 定義被訪問ASCII從站對象類型 */ typedef struct AccessedASCIISlaveType{uint8_t stationAddress;?????? //站地址uint8_t cmdOrder;???????????? //當前命令在命令列表中的位置uint16_t commandNumber;?????? //命令列表中命令的總數uint8_t (*pReadCommand)[17];?? //讀命令列表uint8_t *pLastCommand;??????? //上一次發送的命令uint32_t flagPresetCoil;????? //預置線圈控制標志位uint32_t flagPresetReg;?????? //預置寄存器控制標志位 }ASCIIAccessedSlaveType;

關于從站對象有三個字段需要說明一下。首先我們來看一看“讀命令列表（uint8_t (*pReadCommand)[17]）”字段，與Modbus RTU不同，它是17個字節，這是由Modbus ASCII消息格式決定的。如下：

還有就是flagPresetCoil和flagPresetReg字段。這兩個字段用來表示對線圈和保持寄存器的寫請求。

2.2、實例化對象

我們定義了主站即從站對象類型，我們在使用時就需要實例化這些對象。一般來說一個硬件端口我們將其實例化為一個主站對象。

ASCIILocalMasterType hgraMaster;

/*初始化ASCII主站對象*/

InitializeASCIIMasterObject(&hgraMaster,2,hgraSlave,NULL,NULL,NULL,NULL);

而一個主站對象會管理1到254個從站對象，所以從站對象我們可以將多個從站對象實例組成數組，并將其賦予主站管理。

ASCIIAccessedSlaveType hgraSlave[]={{1,0,2,slave1ReadCommand,NULL,0x00,0x00},{2,0,2,slave2ReadCommand,NULL,0x00,0x00}};

所以，根據主站和從站實例化的條件，我們需要先實例化從站對象才能完整實例化主站對象。在主站的初始化中，我們這里將4的數據處理函數指針初始化為NULL，有一個默認的處理函數會復制給它，該函數是上一版本的延續，在簡單應用時簡化操作。從站的上一個發送的命令指針也被賦值為NULL，因為初始時還沒有命令發送。

2.3、讀從站操作

讀從站操作原理上與以前的版本是一樣的。按照一定的順序給從站發送命令再對收到的消息進行解析。我們對主站及其所管理的從站進行了定義，將發送命令保存于從站對象，將從站列表保存于主站對象，所以我們需要對解析函數進行修改。

/*解析收到的服務器相應信息*/ void ParsingAsciiSlaveRespondMessage(AsciiLocalMasterType *master,uint8_t *recievedMessage, uint8_t *command,uint16_t rxLength) {int i=0;int j=0;uint8_t *cmd=NULL;/*判斷是否為Modbus ASCII消息*/if (0x3A != recievedMessage[0]){return ;}/*判斷消息是否接收完整*/if ((rxLength < 17) || (recievedMessage[rxLength - 2] != 0x0D) || (recievedMessage[rxLength - 1] != 0x0A)){return ;}uint16_t length = rxLength - 3;uint8_t hexMessage[256];if (!CovertAsciiMessageToHex(recievedMessage + 1, hexMessage, length)){return ;}/*校驗接收到的數據是否正確*/if (!CheckASCIIMessageIntegrity(hexMessage, length/2)){return ;}/*判斷功能碼是否有誤*/FunctionCode fuctionCode = (FunctionCode)hexMessage[1];if (CheckFunctionCode(fuctionCode) != MB_OK){return;}if ((command == NULL)||(!CheckMessageAgreeWithCommand(recievedMessage, command))){while(i<master->slaveNumber){if(master->pSlave[i].stationAddress==hexMessage[0]){break;}i++;}if(i>=master->slaveNumber){return;}if((master->pSlave[i].pLastCommand==NULL)||(!CheckMessageAgreeWithCommand(recievedMessage,master->pSlave[i].pLastCommand))){j=FindAsciiCommandForRecievedMessage(recievedMessage,master->pSlave[i].pReadCommand,master->pSlave[i].commandNumber);if(j<0){return;}cmd=master->pSlave[i].pReadCommand[j];}else{cmd=master->pSlave[i].pLastCommand;}}else{cmd=command;}uint8_t hexCommand[256];CovertAsciiMessageToHex(cmd + 1, hexCommand, 14);uint16_t startAddress = (uint16_t)hexCommand[2];startAddress = (startAddress << 8) + (uint16_t)hexCommand[3];uint16_t quantity = (uint16_t)hexCommand[4];quantity = (quantity << 8) + (uint16_t)hexCommand[5];if ((fuctionCode >= ReadCoilStatus) && (fuctionCode <= ReadInputRegister)){HandleAsciiSlaveRespond[fuctionCode - 1](master,hexMessage,startAddress,quantity);} }

解析函數的主要部分是在檢查接收到的消息是否是合法的Modbus ASCII消息。檢查沒問題則調用協議站解析。而最后調用的數據處理函數則是我們需要在具體應用中編寫。在前面主站初始化時，回調函數我們初始化為NULL，實際在協議占中有弱化的函數定義，需要針對具體的寄存器和變量地址實現操作。特別要說明的是，解析Modbus ASCII消息時，在去除開始字符和結束字符后，需要將ASCII碼轉化為二進制數才能完成解析。

2.4、寫從站操作

寫從站操作則是在其它進程請求后，我們標識需要寫的對象再統一處理。對具體哪個從站的寫標識存于主站實例。而該從站的哪些變量需要寫則記錄在從站實例中。

所以在進程檢測到需要寫一個從站時則置位對應的位，即改變flagWriteSlave中的對應位。而需要寫該站的哪些變量則標記flagPresetCoil和flagPresetReg的對應位。修改這些標識都在其它請求更改的進程中實現，而具體的寫操作則在本主站進程中，檢測到標志位的變化統一執行。

這部分不修改協議棧的代碼，因為各站及各變量都至于具體對象相關聯，所以在具體的應用中修改。

3、回歸驗證

考慮到Modbus ASCII和Modbus RTU的相似性，我們設計同樣的的網絡結構。但考慮到Modbus ASCII一般用于小數據量通訊，所以我們設計相對簡單的從站。所以我們設計的網絡為：協議棧建立2個主機，每個主機管理2個從站，每個從站有8個線圈及2個保持寄存器。具體結構如圖：

從上圖我們知道，該Modbus網關需要實現一個Modbus從站用于和上位的通訊；需要實現兩個Modbus主站用于和下位的通訊。

在這個實驗中，讀操作沒有什么需要說的，只需要發送命令解析返回消息即可。所以我們中點描述一下為了方便操作，在需要寫的連續段，我們只要找到第一個請求寫的位置后，就將后續連續可寫數據一次性寫入。修改寫標志位的代碼如下：

/* 修改從站線圈量使能控制 */ static void PresetSlaveCoilControll(uint16_t startAddress,uint16_t endAddress) {if((8<=startAddress)&&(startAddress<=15)&&(8<=endAddress)&&(endAddress<=15)){ModifyWriteRTUSlaveEnableFlag(&hgraMaster,hgraMaster.pSlave[0].stationAddress,true);if((startAddress<=8)&&(8<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x01;}if((startAddress<=9)&&(9<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x02;}if((startAddress<=10)&&(10<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x04;}if((startAddress<=11)&&(11<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x08;}if((startAddress<=12)&&(12<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x10;}if((startAddress<=13)&&(13<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x20;}if((startAddress<=14)&&(14<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x40;}if((startAddress<=15)&&(15<=endAddress)){hgraMaster.pSlave[0].flagPresetCoil|=0x80;}}if((16<=startAddress)&&(startAddress<=23)&&(16<=endAddress)&&(endAddress<=23)){ModifyWriteRTUSlaveEnableFlag(&hgraMaster,hgraMaster.pSlave[1].stationAddress,true);if((startAddress<=16)&&(16<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x01;}if((startAddress<=17)&&(17<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x02;}if((startAddress<=18)&&(18<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x04;}if((startAddress<=19)&&(19<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x08;}if((startAddress<=20)&&(20<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x10;}if((startAddress<=21)&&(21<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x20;}if((startAddress<=22)&&(22<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x40;}if((startAddress<=23)&&(23<=endAddress)){hgraMaster.pSlave[1].flagPresetCoil|=0x80;}}if((24<=startAddress)&&(startAddress<=31)&&(24<=endAddress)&&(endAddress<=31)){ModifyWriteRTUSlaveEnableFlag(&hgpjMaster,hgpjMaster.pSlave[0].stationAddress,true);if((startAddress<=24)&&(24<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x01;}if((startAddress<=25)&&(25<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x02;}if((startAddress<=26)&&(26<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x04;}if((startAddress<=27)&&(27<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x08;}if((startAddress<=28)&&(28<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x10;}if((startAddress<=29)&&(29<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x20;}if((startAddress<=30)&&(30<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x40;}if((startAddress<=31)&&(31<=endAddress)){hgpjMaster.pSlave[0].flagPresetCoil|=0x80;}}if((32<=startAddress)&&(startAddress<=39)&&(32<=endAddress)&&(endAddress<=39)){ModifyWriteRTUSlaveEnableFlag(&hgpjMaster,hgpjMaster.pSlave[1].stationAddress,true);if((startAddress<=32)&&(32<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x01;}if((startAddress<=33)&&(33<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x02;}if((startAddress<=34)&&(34<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x04;}if((startAddress<=35)&&(35<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x08;}if((startAddress<=36)&&(36<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x10;}if((startAddress<=37)&&(37<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x20;}if((startAddress<=38)&&(38<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x40;}if((startAddress<=39)&&(39<=endAddress)){hgpjMaster.pSlave[1].flagPresetCoil|=0x80;}} }

與Modbus RTU一樣也是在請求修改進程中置位索要寫的從站的寫請求標志位和對應參數的寫請求標志位。然后在主站對象的進程中檢測標志位，根據標志位的狀態來實現操作。

告之：源代碼可上Github下載：https://github.com/foxclever/Modbus

歡迎關注：

總結

以上是生活随笔為你收集整理的实现Modbus ASCII多主站应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。