APP
Modbus是由Modicon（現為施耐德電氣公司的一個品牌）在1979年發明的，是全球第一個真正用于工業現場的總線協議。 ModBus網絡是一個工業通信系統，由帶智能終端的可編程序控制器和計算機通過公用線路或局部專用線路連接而成。其系統結構既包括硬件、亦包括軟件。它可應用于各種數據采集和過程監控。 ModBus網絡只有一個主機，所有通信都由他發出。網絡可支持247個之多的遠程從屬控制器，但實際所支持的從機數要由所用通信設備決定。采用這個系統，各PC可以和中心主機交換信息而不影響各PC執行本身的控制任務。
Modbus 協議
abel-module="para" style="word-wrap: break-word; margin-bottom: 15px; white-space: normal; text-transform: none; word-spacing: 0px; zoom: 1; color: rgb(51,51,51); font: 14px/24px arial, 宋體, sans-serif; widows: 1; letter-spacing: normal; background-color: rgb(255,255,255); text-indent: 2em; -webkit-text-stroke-width: 0px">為更好地普及和推動Modbus在基于以太網上的分布式應用，目前施耐德公司已將Modbus協議的所有權移交給IDA（Interface for Distributed Automation，分布式自動化接口）組織，并成立了Modbus-IDA組織，為Modbus今后的發展奠定了基礎。在中國，Modbus已經成為國家標準GB/T19582-2008。據不完全統計：截止到2007年，Modbus的節點安裝數量已經超過了1000萬個。
Modbus協議是應用于電子控制器上的一種通用語言。通過此協議，控制器相互之間、控制器經由網絡（例如以太網）和其它設備之間可以通信。它已經成為一通用工業標準。有了它，不同廠商生產的控制設備可以連成工業網絡，進行集中監控。此協議定義了一個控制器能認識使用的消息結構，而不管它們是經過何種網絡進行通信的。它描述了一控制器請求訪問其它設備的過程，如何回應來自其它設備的請求，以及怎樣偵測錯誤并記錄。它制定了消息域格局和內容的公共格式。
當在一Modbus網絡上通信時，此協議決定了每個控制器須要知道它們的設備地址，識別按地址發來的消息，決定要產生何種行動。如果需要回應，控制器將生成反饋信息并用Modbus協議發出。在其它網絡上，包含了Modbus協議的消息轉換為在此網絡上使用的幀或包結構。這種轉換也擴展了根據具體的網絡解決節地址、路由路徑及錯誤檢測的方法。
特點
Modbus具有以下幾個特點：
（1）標準、開放，用戶可以免費、放心地使用Modbus協議，不需要交納許可證費，也不會侵犯知識產權。目前，支持Modbus的廠家超過400家，支持Modbus的產品超過600種。
（2）Modbus可以支持多種電氣接口，如RS-232、RS-485等，還可以在各種介質上傳送，如雙絞線、光纖、無線等。
（3）Modbus的幀格式簡單、緊湊，通俗易懂。用戶使用容易，廠商開發簡單。
Modbus網絡傳輸
主設備可單獨和從設備通信，也能以廣播方式和所有從設備通信。如果單獨通信，從設備返回一消息作為回應，如果是以廣播方式查詢的，則不作任何回應。Modbus協議建立了主設備查詢的格式：設備（或廣播）地址、功能代碼、所有要發送的數據、一錯誤檢測域。
從設備回應消息也由Modbus協議構成，包括確認要行動的域、任何要返回的數據、和一錯誤檢測域。如果在消息接收過程中發生一錯誤，或從設備不能執行其命令，從設備將建立一錯誤消息并把它作為回應發送出去。
其它類型傳輸
在其它網絡上，控制器使用對等技術通信，故任何控制器都能初始化和其它控制器的通信。這樣在單獨的通信過程中，控制器既可作為主設備也可作為從設備。提供的多個內部通道可允許同時發生的傳輸進程。
在消息位，Modbus協議仍提供了主—從原則，盡管網絡通信方法是“對等”。如果一控制器發送一消息，它只是作為主設備，并期望從從設備得到回應。同樣，當控制器接收到一消息，它將建立一從設備回應格式并返回給發送的控制器。
查詢回應周期
（1）查詢
查詢消息中的功能代碼告之被選中的從設備要執行何種功能。數據段包含了從設備要執行功能的任何附加信息。例如功能代碼03是要求從設備讀保持寄存器并返回它們的內容。數據段必須包含要告之從設備的信息：從何寄存器開始讀及要讀的寄存器數量。錯誤檢測域為從設備提供了一種驗證消息內容是否正確的方法。
（2）回應
如果從設備產生一正常的回應，在回應消息中的功能代碼是在查詢消息中的功能代碼的回應。數據段包括了從設備收集的數據：像寄存器值或狀態。如果有錯誤發生，功能代碼將被修改以用于指出回應消息是錯誤的，同時數據段包含了描述此錯誤信息的代碼。錯誤檢測域允許主設備確認消息內容是否可用。
傳輸方式
在ModBus系統中有2種傳輸模式可選擇。這2種傳輸模式與從機PC通信的能力是同等的。選擇時應視所用ModBus主機而定，每個ModBus系統只能使用一種模式，不允許2種模式混用。一種模式是ASCII（美國信息交換碼），另一種模式是RTU（遠程終端設備）。
用戶選擇想要的模式，包括串口通信參數（波特率、校驗方式等），在配置每個控制器的時候，在一個Modbus網絡上的所有設備都必須選擇相同的傳輸模式和串口參數。所選的ASCII或RTU方式僅適用于標準的Modbus網絡，它定義了在這些網絡上連續傳輸的消息段的每一位，以及決定怎樣將信息打包成消息域和如何解碼。在其它網絡上（像MAP和Modbus Plus）Modbus消息被轉成與串行傳輸無關的幀。
傳輸模式特性
ASCII可打印字符便于故障檢測，而且對于用高級語言（如Fortran）編程的主計算機及主PC很適宜。RTU則適用于機器語言編程的計算機和PC主機。
用RTU模式傳輸的數據是8位二進制字符。如欲轉換為ASCII模式，則每個RTU字符首先應分為高位和低位兩部分，這兩部分各含4位，然后轉換成十六進制等量值。用以構成報文的ASCII字符都是十六進制字符。ASCII模式使用的字符雖是RTU模式的兩倍，但ASCII數據的譯碼和處理更為容易一些，此外，用RTU模式時報文字符必須以連續數據流的形式傳送，用ASCII模式，字符之間可產生長達1s的間隔，以適應速度較慢的機器。
控制器能設置為兩種傳輸模式（ASCII或RTU）中的任何一種在標準的Modbus網絡通信。
ASCII模式
當控制器設為在Modbus網絡上以ASCII（美國標準信息交換代碼）模式通信，一個信息中的每8位字節作為2個ASCII字符傳輸，如數值63H用ASCII方式時，需發送兩個字節，即ASCII“6"（0110110）和ASCII”3“（0110011），ASCII字符占用的位數有7位和8位，國際通用7位為多。這種方式的主要優點是字符發送的時間間隔可達到1秒而不產生錯誤。
代碼系統
· 消息中的每個ASCII字符都是一個十六進制字符組成
每個字節的位
· 1個起始位
· 7個數據位，最小的有效位先發送
· 1個奇偶校驗位，無校驗則無
1個停止位（有校驗時），2個Bit（無校驗時）
錯誤檢測域
· LRC(縱向冗長檢測)
RTU模式
當控制器設為在Modbus網絡上以ASCII模式通信，在消息中的每個8Bit字節按照原值傳送，不做處理，如63H，RTU將直接發送01100011。這種方式的主要優點是：數據幀傳送之間沒有間隔，相同波特率下傳輸數據的密度要比ASCII高，傳輸速度更快[1] 。
代碼系統
8位二進制，十六進制數0...9，A...F
消息中的每個8位域都是一或兩個十六進制字符組成
每個字節的位
1個起始位
8個數據位，最小的有效位先發送
1個奇偶校驗位，無校驗則無
1個停止位（有校驗時），2個Bit（無校驗時）
數據校驗方式
CRC
CRC域是兩個字節，包含一16位的二進制值。它由傳輸設備計算后加入到消息中。接收設備重新計算收到消息的CRC，并與接收到的CRC域中的值比較，如果兩值不同，則有誤。
CRC是先調入一值是全“1”的16位寄存器，然后調用一過程將消息中連續的8位字節各當前寄存器中的值進行處理。僅每個字符中的8Bit數據對CRC有效，起始位和停止位以及奇偶校驗位均無效。
CRC產生過程中，每個8位字符都單獨和寄存器內容相異或（XOR），結果向最低有效位方向移動，最高有效位以0填充。LSB被提取出來檢測，如果LSB為1，寄存器單獨和預置的值或一下，如果LSB為0，則不進行。整個過程要重復8次。在最后一位（第8位）完成后，下一個8位字節又單獨和寄存器的當前值相異或（XOR）。最終寄存器中的值，是消息中所有的字節都執行之后的CRC值。
CRC添加到消息中時，低字節先加入，然后高字節。
CRC-16錯誤校驗程序如下：報文（此處只涉及數據位，不指起始位、停止位和任選的奇偶校驗位）被看作是一個連續的二進制，其最高有效位（MSB）首選發送。報文先與X↑16相乘（左移16位），然后看X↑16+X↑15+X↑2+1除，X↑16+X↑15+X↑2+1可以表示為二進制數11000，0000，0000，0101。整數商位忽略不記，16位余數加入該報文（MSB先發送），成為2個CRC校驗字節。余數中的1全部初始化，以免所有的零成為一條報文被接收。經上述處理而含有CRC字節的報文，若無錯誤，到接收設備后再被同一多項式（X↑16+X↑15+X↑2+1）除，會得到一個零余數（接收設備核驗這個CRC字節，并將其與被傳送的CRC比較）。全部運算以2為模（無進位）。
習慣于成串發送數據的設備會首選送出字符的最右位（LSB-最低有效位）。而在生成CRC情況下，發送首位應是被除數的最高有效位MSB。由于在運算中不用進位，為便于操作起見，計算CRC時設MSB在最右位。生成多項式的位序也必須反過來，以保持一致。多項式的MSB略去不記，因其只對商有影響而不影響余數。
生成CRC-16校驗字節的步驟如下：
①裝如一個16位寄存器，所有數位均為1。
②該16位寄存器的高位字節與開始8位字節進行“異或”運算。運算結果放入這個16位寄存器。
③把這個16寄存器向右移一位。
④若向右（標記位）移出的數位是1，則生成多項式10，1000，000，0000，001和這個寄存器進行“異或”運算；若向右移出的數位是0，則返回③。
⑤重復③和④，直至移出8位。
⑥另外8位與該十六位寄存器進行“異或”運算。
⑧這個16位寄存器的內容即2字節CRC錯誤校驗，被加到報文的最高有效位。
另外，在某些非ModBus通信協議中也經常使用CRC16作為校驗手段，而且產生了一些CRC16的變種，他們是使用CRC16多項式X↑16+X↑15+X↑2+1，單首次裝入的16位寄存器為0000；使用CRC16的反序X↑16+X↑14+X↑1+1，首次裝入寄存器值為0000或FFFFH。
CRC簡單函數如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 | unsignedchar*puchMsg;/*要進行CRC校驗的消息*/unsignedshortusDataLen;/*消息中字節數*/unsignedshortCRC16(puchMsg,usDataLen){unsignedcharuchCRCHi=0xFF;/*高CRC字節初始化*/unsignedcharuchCRCLo=0xFF;/*低CRC字節初始化*/unsigneduIndex;/*CRC循環中的索引*/while(usDataLen--)/*傳輸消息緩沖區*/{uIndex=uchCRCHi^*puchMsg++;/*計算CRC*/uchCRCHi=uchCRCLo^auchCRCHi[uIndex];uchCRCLo=auchCRCLo[uIndex];}return((uchCRCHi<<8)|uchCRCLo);}/*CRC高位字節值表*/staticunsignedcharauchCRCHi[]={0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40};//CRC低位字節值表staticcharauchCRCLo[]={0x00,0xC0,0xC1,0x01,0xC3,0x03,0x02,0xC2,0xC6,0x06,0x07,0xC7,0x05,0xC5,0xC4,0x04,0xCC,0x0C,0x0D,0xCD,0x0F,0xCF,0xCE,0x0E,0x0A,0xCA,0xCB,0x0B,0xC9,0x09,0x08,0xC8,0xD8,0x18,0x19,0xD9,0x1B,0xDB,0xDA,0x1A,0x1E,0xDE,0xDF,0x1F,0xDD,0x1D,0x1C,0xDC,0x14,0xD4,0xD5,0x15,0xD7,0x17,0x16,0xD6,0xD2,0x12,0x13,0xD3,0x11,0xD1,0xD0,0x10,0xF0,0x30,0x31,0xF1,0x33,0xF3,0xF2,0x32,0x36,0xF6,0xF7,0x37,0xF5,0x35,0x34,0xF4,0x3C,0xFC,0xFD,0x3D,0xFF,0x3F,0x3E,0xFE,0xFA,0x3A,0x3B,0xFB,0x39,0xF9,0xF8,0x38,0x28,0xE8,0xE9,0x29,0xEB,0x2B,0x2A,0xEA,0xEE,0x2E,0x2F,0xEF,0x2D,0xED,0xEC,0x2C,0xE4,0x24,0x25,0xE5,0x27,0xE7,0xE6,0x26,0x22,0xE2,0xE3,0x23,0xE1,0x21,0x20,0xE0,0xA0,0x60,0x61,0xA1,0x63,0xA3,0xA2,0x62,0x66,0xA6,0xA7,0x67,0xA5,0x65,0x64,0xA4,0x6C,0xAC,0xAD,0x6D,0xAF,0x6F,0x6E,0xAE,0xAA,0x6A,0x6B,0xAB,0x69,0xA9,0xA8,0x68,0x78,0xB8,0xB9,0x79,0xBB,0x7B,0x7A,0xBA,0xBE,0x7E,0x7F,0xBF,0x7D,0xBD,0xBC,0x7C,0xB4,0x74,0x75,0xB5,0x77,0xB7,0xB6,0x76,0x72,0xB2,0xB3,0x73,0xB1,0x71,0x70,0xB0,0x50,0x90,0x91,0x51,0x93,0x53,0x52,0x92,0x96,0x56,0x57,0x97,0x55,0x95,0x94,0x54,0x9C,0x5C,0x5D,0x9D,0x5F,0x9F,0x9E,0x5E,0x5A,0x9A,0x9B,0x5B,0x99,0x59,0x58,0x98,0x88,0x48,0x49,0x89,0x4B,0x8B,0x8A,0x4A,0x4E,0x8E,0x8F,0x4F,0x8D,0x4D,0x4C,0x8C,0x44,0x84,0x85,0x45,0x87,0x47,0x46,0x86,0x82,0x42,0x43,0x83,0x41,0x81,0x80,0x40}; |
LRC
LRC錯誤校驗用于ASCII模式。這個錯誤校驗是一個8位二進制數，可作為2個ASCII十六進制字節傳送。把十六進制字符轉換成二進制，加上無循環進位的二進制字符和二進制補碼結果生成LRC錯誤校驗（參見圖）。這個LRC在接收設備進行核驗，并與被傳送的LRC進行比較，冒號（：）、回車符號（CR）、換行字符（LF）和置入的其他任何非ASCII十六進制字符在運算時忽略不計。
內容來自百科網