Implementation of simple Modbus protocol based on AVR128

Modbus Communication Protocol Modicon company 1979 in the development, applicable to industrial Fieldbus protocol control. The Modbus communication system consists of a node of the chip and a common transmission line with the composition programmable control, which is designed to collect and monitor data from multiple nodes. Modbus protocol adopts master-slave mode, communication system has multiple nodes from a host computer monitor. Supports up to 247 nodes from a node. Each slave has its own independent slave address. and change the address can be recognized by the host.

The communication system that can support Modbus protocol has RS-232. rs-422,rs-485 and so on. At the same time, Modbus protocol has the characteristics of standard, open, free, simple frame format and so on by the majority of project teachers.

The Modbus protocol transmits data using two modes of ASCII and RTU. The data expressed in ASCII transmission mode is easy to understand. Convenient and PC direct communication identification, but the disadvantage is that the use of single-byte representation of a data, the transmission of the same data need a lot of other frames and time. The RTU mode uses a compressed hexadecimal representation. One byte can compress two data, so the RTU mode can transmit many other data in the same frame number.

Modbus Data frame check is divided into two ways: CRC cyclic redundancy check and LRC longitudinal redundancy check.

Use the following Proteus Simulation atmega128. two tablets - serial communication between the serial communication, the running is simple Modbus agreement.

The simulation diagram looks like the following:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvzmvuz3llahvkawu=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/center ">

Description: The U1 uses 1602 to display the received data.

The data frame is used in RTU mode, but it is easy to display for 1602. The transmitted data frame message uses the ASCII representation of the 0x3x (0,1,2,3 ... equal number) so that it can be directly fed into 1602 for display. So as to facilitate simulation). The three keys in the middle of the picture are the three interrupts of the U2.

After pressing, U2 a single shot to send a frame of data. The data content is 0x30, 0x31,0x33,0x01. 0x34. 0X37.

according toModbusProtocol0X30,0X31is the slave address that is represented,0X33is the character that represents the command. 0x01represents the data field length,0x34represents a data field. 0X37it's done.LRCchecksum. we simplify it in such a way as to facilitate1602to display, among0x01is aASCIIspaces in the code"'can also be in1602in the display.

Single Chip microcomputer U1 of the PB Mouth and PE the port states show the LRC Check bytes and data field first byte.

when you press the button1 the time U2 send a data frame, U1 receive and continue the checksum on the received data, assuming the checksum is correct. Then the display.

Press the button1 results such as the following

middle of on because it's a space. ASCII code value so 1602 displays a space. Because the data field is the way I use arrays to store data. the LCD Display code is displayed in the C language . So the check byte is not displayed. I project it to Portb , where Portb is 0X37. This also verifies the normal transmission of this simple Modbus protocol.

Press Move U2 of the Button2 can proactively produce a LRC checksum error. (I did not use the standard LRC check when I checked the code .) Only the cumulative check is performed). U2 deliberately changes the checksum when the data frame is filled. Sends the changed data frame to the U1, andU1 The checksum after the receipt produces a checksum error. Press the button2 Results

from the virtual terminal we can see. We manually changed the checksum value, changed from 0x37 to 0XFF, then the U1 received data to verify that will produce a checksum error prompt.

。 The actual check results are still 0X37, but we officer before the transmission of the test changed to 0XFF. Causes the receiver to verify the 0x37!=0xff, resulting in an error:

。

Press the Button3 generates a data frame error. Press button3,U2 deliberately send an incomplete data frame. Assuming that the data frame is incomplete,U1 cannot wait indefinitely. So U1 uses timer 0 to make a time-out inference, assuming that the data frame is still not complete, if it exceeds 10ms, then infer that the data frame is an error frame.

。

The results are as follows.

in the event 3 we are able to make U2 does not send a checksum, causing the frame data to be incomplete. U1 waits for 10ms to determine that the data frame is a frame error.

The simulation program and simulation project are stored to the network address

Shareid=368414814&uk=840368654&third=0 ">http://yun.baidu.com/share/link?

Shareid=368414814&uk=840368654&third=0

The project code for U1 and U2 is included in the respective main directory, respectively. Simulation files for the ISIS directory.

I hope to be of some help to you.

88

Copyright notice: This article Bo Master original article. Blog, not reproduced without consent.

Implementation of simple Modbus protocol based on AVR128