V20 Modbus

[Shinyoung Gedris]

Modbusis a serial communication protocol developed by Modicon published by Modicon in 1979 for use with its programmable logic controllers (PLCs). In simple terms, it is a method used for transmitting information over serial lines between electronic devices. The device requesting the information is called the Modbus Client and the devices supplying information are Modbus Servers. In a standard Modbus network, there is one Client and up to 247 Servers, each with a unique Server Address from 1 to 247. The Client can also write information to the Servers.

The official Modbus specification can be found at

Modbus is an open protocol, meaning that it's free for manufacturers to build into their equipment without having to pay royalties. It has become a standard communications protocol in industry, and is now the most commonly available means of connecting industrial electronic devices. It is used widely by many manufacturers throughout many industries. Modbus is typically used to transmit signals from instrumentation and control devices back to a main controller or data gathering system, for example a system that measures temperature and humidity and communicates the results to a computer. Modbus is often used to connect a supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems. Versions of the Modbus protocol exist for serial lines (Modbus RTU and Modbus ASCII) and for Ethernet (Modbus TCP).

The data is sent as series of ones and zeroes called bits. Each bit is sent as a voltage. Zeroes are sent as positive voltages and a ones as negative. The bits are sent very quickly. A typical transmission speed is 9600 baud (bits per second).

When troubleshooting problems, it can be helpful to see the actual raw data being transmitted. Long strings of ones and zeroes are difficult to read, so the bits are combined and shown in hexadecimal. Each block of 4 bits is represented by one of the sixteen characters from 0 to F.

Information is stored in the Server device in four different tables. Two tables store on/off discrete values (coils) and two store numerical values (registers). The coils and registers each have a read-only table and read-write table. Each table has 9999 values. Each coil or contact is 1 bit and assigned a data address between 0000 and 270E. Each register is 1 word = 16 bits = 2 bytes and also has data address between 0000 and 270E.

Coil/Register Numbers can be thought of as location names since they do not appear in the actual messages. The Data Addresses are used in the messages. For example, the first Holding Register, number 40001, has the Data Address 0000. The difference between these two values is the offset. Each table has a different offset. 1, 10001, 30001 and 40001.

Each server in a network is assigned a unique unit address from 1 to 247. When the client requests data, the first byte it sends is the Server address. This way each server knows after the first byte whether or not to ignore the message.

CRC stands for Cyclic Redundancy check. It is two bytes added to the end of every modbus message for error detection. Every byte in the message is used to calculate the CRC. The receiving device also calculates the CRC and compares it to the CRC from the sending device. If even one bit in the message is received incorrectly, the CRCs will be different and an error will result. .

The example for FC03 shows that register 40108 contains AE41 which converts to the 16 bits 1010 1110 0100 0001 Great! But what does it mean? Well, it could mean a few things. Register 40108 could be defined as any of these 16-bit data types:

A 32-bit double precision IEEE floating point number. This is a mathematical formula that allows any real number (a number with decimal points) to represented by 32 bits with an accuracy of about seven digits. AE41 5652 = -4.395978 E-11 Here is a spreadsheet IEEE float calculator for inputs of 4 bytes or 2 words. To download a copy, right click and select Save Target As...

The Modbus specification doesn't define exactly how the data is stored in the registers. Therefore, some manufacturers implemented modbus in their equipment to store and transmit the higher byte first followed by the lower byte. (AE before 41). Alternatively, others store and transmit the lower byte first (41 before AE). Similarly, when registers are combined to represent 32-bit data types, Some devices store the higher 16 bits (high word) in the first register and the remaining low word in the second (AE41 before 5652) while others do the opposite (5652 before AE41) It doesn't matter which order the bytes or words are sent in, as long as the receiving device knows which way to expect it. For example, if the number 29,235,175,522 was to be sent as a 32 bit unsigned integer, it could be arranged any of these four ways.

Modbus RTU and Modbus ASCII talk the same protocol. The only difference is that the bytes being transmitted over the wire are presented as binary with RTU and as readable ASCII with Modbus RTU. important to note about RTU is that the RTU message does not have a Start_of_text indication. The receiving party in the communications uses a "silent" time in order to determine the start of a new message. ASCII does have a start-of-text token. Binary messages are shorter than ASCII and therefore theoretically faster to transmit/receive. You may be happy to see update rates of about 100 ms in your HMI/SCADA and could choose either communication.

Summary:

- use RTU is possible

- use ASCII in case RTU is giving timeout problems on WinNT or when using slow communications media like 300 bps or dialup modems Most OPC Servers for Modbus support ASCII as well as RTU communications..

Since the range of the analog output holding registers is 40001 to 49999, it implies that there cannot be more than 9999 registers. Although this is usually enough for most applications, there are cases where more registers would be beneficial. Registers 40001 to 49999 correspond to data addresses 0000 to 270E. If we utilize the remaining data addresses 270F to FFFF, over six times as many registers can be available, 65536 in total. This would correspond to register numbers from 40001 to 105536. Many modbus software drivers (for Client PCs) were written with the 40001 to 49999 limits and cannot access extended registers in server devices. And many server devices do not support maps using the extended registers. But on the other hand, some server devices do support these registers and some Client software can access it, especially if custom software is written.

Since a single byte is normally used to define the server address and each server on a network requires a unique address, the number of server on a network is limited to 256. The limit defined in the modbus specification is even lower at 247. To get beyond this limit, a modification can be made to the protocol to use two bytes for the address. The client and the servers would all be required to support this modification. Two byte addressing extends the limit on the number of servers in a network to 65535. By default, the Simply Modbus software uses 1 byte addressing. When an address greater than 255 is entered, the software automatically switches to 2 byte addressing and stays in this mode for all addresses until the 2 byte addressing is manually turned off.

I have never used modbus protocol before and I am trying to get data from a 3rd party sensor in our facility using Modbus TCP. I have installed the NI Modbus Library v1.2.1.42 using the VI package manager. It looks like I am able to connect, however I can't seem to get the data.

I was able to connect with the provided example in the modbus library but it errored out with any command I gave it. I tried to create my own basic VI to pull the data with no luck (see attached snippet). I incremented/decremented the register number by 1 to see if there was an offset (i read that somewhere) and that did not help.

I was close on my first attempt, just needed to omit the leading 4 from the register input. It also defaults to the first device/unit so I had to specify I wanted the 5th unit/device. Also no idea why the help menu of the "Set unit ID" VI says it won't work for TCP, because it does work and you have to use it if you have multiple devices.

Yes, Set Unit ID definitely works and may be needed for TCP/IP. I think it is a documentation error. I think someone thought that Unit ID isn't needed because the IP address helps identify the device. However, certain devices definitely need a unit ID. For example, a remote serial server working off of ethernet. There is one ethernet port to the device and it has an IP, but if it has multiple serial ports on it, you need the unit ID to know which serial port it is talking to!

I'm looking at a small simple project with a Samba SM70-J. I'm running into quite an issue trying to figure out a modbus tcp connection. I'm able to see the device in modscan, and other PLC's as well. But I can't seem to get my configuration right in Visilogic. Would anyone happen to be available to help me troubleshoot this?

You can't hang the Modbus Read block on the rail. It's initiating a communication every scan and not giving it time to respond. In Modbus TCP land you also have to connect the socket first. If you lose the connection you'll have to trigger your connect logic again. If your application is continuous data transfer, you can leave it connected to the socket. If it's periodic or you change to a different Modbus slave, you'll have to disconnect first before you connect to the new slave.

Unfortunately you can't convert a V280 to an SM70, so I did a little hacking and made it into an SM70 for you. I don't know what your IP addresses are so you'll have to go into the blocks and edit those.

Thanks a lot for your time, Joe. I am only using one device as a slave, and at the end of the project, the goal is to not even need a switch in this panel. I only ever look to read values from the remote IO unit that I'm using.

I hadn't yet encountered the connect/close FB in any of the documentation I had been looking over, thanks for including that with clear instructions. I'm a bit of a millennial and spoiled by the niceties of using autonomous configuration for things like this :D.

3a8082e126