Control.com - Nerds in Control

Are the coils/registers a part of the slave/master devices? If I'm using two PC's as master slave, where are the coils/registers? How can they be accessed?

Chris

Coils and registers are just names for memory addresses. The other way to look at it is that they are just pre-defined variable names. A coil is a boolean (bit) variable, and a register is an integer (word) variable.

There are discrete inputs (read-only boolean), coils (read-write boolean), input registers (read-only integer), and holding registers (read-write integer).

The Modbus protocol defines arrays of boolean and integer addresses. The memory addresses are in the "slave" or "server" (both words mean the same thing). The number of coils or registers actually present depends on what the device designer felt was necessary.

The software in the "master" or "client" uses the Modbus protocol to issue a "request" (command) for the values in the specified addresses. The slave (server) replies with a "response" which contains the data. If the master doesn't issue a request, the slave remains silent.

The Modbus protocol commands are called "functions". The functions are numbered 1, 2, 3, 4, etc. Each function does one thing - read or write one or more coils or registers. So, if you want to read the state of a limit switch, you would call the appropriate software function to read the discrete input which corresponds to it. If you wanted to turn on a valve, you would call he appropriate software function to write to the coil.

Thanks for the explanation, but now I'm a little confused. I thought that master and server referred to the same equipment, as well as slave and client referring to the same equipment. Am I wrong about that?

Chris

A "slave" is the same as a "server", and a "master" is the same as a "client". The terms "slave" and "master" originate with the older serial versions of the protocol, while "server" and "client" came into use with the Ethernet version (it's the terminology the computer industry uses).

For example, your web browser is a "client" which sends a request to the control.com web server, which either responds with the web page you asked for, or "posts" the message you sent.

In the same way, a Modbus (or other protocol) "master" sends a request to an I/O module, which responds with the state of the inputs, or sets the outputs to the state you requested.

Essentially, a client or master sends requests, and a server or slave responds to them.

Right. Thanks for clearing that up. Right now I'm writing two simple programs in C++ to act as Master/Slave. I'm having a problem with the slave portion. I can communicate with another computer that is running the master.exe, and I know the MODBUS command protocol that should come from the master. The problem is, once I have it, how do I access the registers values to read from or write to them? I've searched for a command to do this, but haven't been able to find one.

Chris

The Modbus "registers" are just data values in the slave (server). Section 4.3 (MODBUS Data model) in the "MODBUS Application Protocol Specification V1.1b" discusses this point.

If you are writing a slave, its up to you where the data is kept in the slave. You might for example have several arrays of data and simply store the data in there. The "registers" are just part of your program. The Modbus protocol describes what the data should look like when it goes out on the wire. It doesn't tell you how to write your program.

A client (master) sends a request to a server (slave). For example, if a client sends a request for function 2 with a quantity of 1 and an address of 5, the server will respond with the value of whatever was in the memory location it calls "discrete input 5".

The register locations don't even necessarily have to exist. Suppose for example you are making a very simple server (slave) device that acts as an input device with 6 inputs. If we take the above example (function 2, quantity 1, address 5), then the server simply has to read the state of the input and send an appropriate reply to the client. As long as the client gets the reply it was expecting, it's happy.

If you have a server with a large register map (data table), then it can be simpler to implement it as an array (or several arrays) of data. The communications routines then just have to read the appropriate array locations to get the data they need. You can overlap these arrays if you wish so that for example coils are stored in holding registers, or holding registers are the same as input registers. Or, you can make them all separate.

Another way of putting this is that normally a server (slave) is something that performs a job, and the client (master) is something that asks for the job to be done. Modbus is simply the language that both parties use to talk to each other. How the job actually gets done is up to the server.

If you are still having difficulty understanding this, then perhaps if you describe what your slave is supposed to do (besides communicate) we can put this description into a more tangible form.

That definitely cleared things up. I've scanned through the protocol several times and have never seen that. Didn't look close enough I guess. Thanks.

It might be helpful to see a working Modbus Master and Slave in action. Minimally, it would be helpful to have a known working slave when developing the master and vice versa.

You can download Automated Solutions' Modbus Master and Slave ActiveX Control trial editions, which are fully functioning for 30 days.

Modbus RTU & ASCII Master
http://automatedsolutions.com/products/modbusrtu.asp

Modbus/TCP Master
http://automatedsolutions.com/products/modbustcp.asp

Modbus RTU, ASCII, and TCP Slave
http://automatedsolutions.com/products/modbusslave.asp

Each comes with a ready to run example application called MiniHMI. So you don't need to write any code. The products allow you to read/write the complete range of Modbus registers and discretes.

Ultimately, you might want to save time and effort and use the ActiveX Controls in your c++ application. They are mature products that are field tested and implement a very broad range of Modbus functions including the ability to intentionally force bad packet to test slave response.