ModBus

ModBus is a communications protocol that was first designed for use with Modicon brand PLCs, and has become one of the most popular fieldbus protocols, especially in North America.

One of the reasons that ModBus is popular is that it is capable of hiding a lot of the gory details from the user. With ModBus you don't have to worry much about the details of how data gets transferred between two "boxes". Instead you define a mapping between items in one box and the corresponding items in another box. For example, in the above diagram RAM location 198 in the SPLat has been visualized as mapped to the speed control register in the VSD (Variable Speed Drive). Once ModBus is configured the effect would be that whenever the program in the SPLat changes the contents of RAM location 198, the speed of the motor driven by the VSD will change accordingly. Similarly, if the status flag in the VSD gets set (maybe denoting a problem), semaphore 56 in the SPLat will reflect the change. All this happens without the programmer needing to understand the messages that flow between the two boxes, although you must specify the data flow.

In reality it can be a bit more complicated than that, but it is still considerably less complicated than having to actually compose and transmit messages (datagrams), track their progress and handle errors and lost messages.

Masters and Slaves

ModBus is a Master/Slave protocol. What that means is that in a system that uses ModBus there must be one device that is the master and all others must be slaves. Data transfers are always initiated by the master, and a slave may only "speak" when first "spoken to" by the master. One master and one or more slaves share a single communications channel. Normally every slave will hear every message sent by a master. Depending on the type of channel, every slave may or may not hear every other slaves' transmissions.

Each slave must have a unique address in the range 1 to 247.

A typical ModBus "conversation" consists of a query from the master to a slave, followed by the slave's response to the query. A very small number of queries may be broadcast to all slaves in a system using address 0, in which case no response is possible. A query will most commonly be either a request for data from a slave or a transmission of data to a slave. In the first instance the slave's response contains the requested data. In the second case the slave's response is an acknowledgement the the data was received.

If a slave fails to decode a query correctly it stays silent. The master will then note the absence of a response within a certain time limit and take some corrective action. If a query decodes correctly but contains an illegal request (say a bad data address), the slave will send back a special error response.

A SPLat can be configured as either a master or a slave. The two modes have differing programming requirements.  Note that 32-bit controllers allow use of Modbus on multiple ports.  It has been successfully tried with Master mode on one port and Slave mode on another.

SPLat as a ModBus Slave

It is very easy to program a SPLat to be a slave. All you have to do is correctly configure and activate a Communications Control Block (CCB). This basically configures the SPLat with the right communications parameters to match the master. Thereafter the master takes all the the initiatives and your slave is its obedient ... slave. If the master is a non-SPLat device, you will need to configure it according to its documentation. If you are using a SPLat also as the master, you configure it according to the documentation that follows. In either case you need to know which query types we have implemented in SPLat, so you can configure your master to issue queries the slave SPLat is able to respond to.

SPLat as a ModBus Master

Making a SPLat into a ModBus master is a bit more complicated. Unavoidably you must configure the master to issue specific queries, so you need some understanding of the main query types. However, we give you an easy way of specifying the queries. You can concentrate on the data you want to move between units without worrying about the details of datagram generation, acknowledge timing or lost messages.