PLC & Control

Simply the easiest way to test and debug Modbus systems

No install program. Just download, unzip and run. Free demonstration version with full functionality.

Features

Functions as a Modbus RTU or Modbus ASCII Master

Connects to RTU/ASCII Slave devices using Modicon 984 (5 digit addressing) protocol

All information is entered and displayed in one window.

Displays the traffic on the serial port.

Change data types and byte and word ordering with a click to determine the format of the reply string without repolling.

Supports multiple data types in the same message.

Supports Standard Modbus and Enron Modbus

Can include RTS delay (required for some radios)

Supports 2 byte slave IDs

A notes column allows labeling the results

Allows saving and restoring configuration settings

Write window allows writing single and multiple values

Save the communication log to a text file and more...

See the online manual

Try the demo before you buy.

See the tutorial on How Modbus Works

What is Modbus?

Modbus is a communication protocol developed by Modicon systems. 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 Master and the devices supplying information are Modbus Slaves. In a standard Modbus network, there is one Master and up to 247 Slaves, each with a unique Slave Address from 1 to 247. The Master can also write information to the Slaves.

The official Modbus specification can be found at http://www.modbus-ida.org/

What is it used for?

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 very common protocol 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.

How does it work?

Modbus is transmitted over serial lines between devices. The simplest setup would be a single serial cable connecting the serial ports on two devices, a Master and a Slave.

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).

What is hexadecimal?

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.

0000 = 0	>0100 = 4	1000 = 8	1100 = C
0001 = 1	0101 = 5	1001 = 9	1101 = D
0010 = 2	0110 = 6	1010 = A	1110 = E
0011 = 3	0111 = 7	1011 = B	1111 = F

Each block of 8 bits (called a byte) is represented by one of the 256 character pairs from 00 to FF.

How is data stored in Standard Modbus?

Information is stored in the Slave 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	Data Addresses	Type	Table Name
1-9999	0000 to 270E	Read-Write	Discrete Output Coils
10001-19999	0000 to 270E	Read-Only	Discrete Input Contacts
30001-39999	0000 to 270E	Read-Only	Analog Input Registers
40001-49999	0000 to 270E	Read-Write	Analog Output Holding Registers

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.

What is the Slave ID?

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

What is a function code?

The second byte sent by the Master is the Function code. This number tells the slave which table to access and whether to read from or write to the table.

Function Code	Action	Table Name
01(01 hex)	Read	Discrete Output Coils
05(05 hex)	Write	single Discrete Output Coil
15(0F hex)	Write	multiple Discrete Output Coils
02(02 hex)	Read	Discrete Input Contacts
04 (04 hex)	Read	Analog Input Registers
03 (03 hex)	Read	Analog Output Holding Registers
06 (06 hex)	Write	single Analog Output Holding Register
16 (10 hex)	Write	multiple Analog Output Holding Registers

What is a CRC?

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.

Here is a spreadsheet CRC calculator for messages up to 16 bytes. To download a copy, right click and select Save Target As...

What are the formats of Modbus commands and responses?

Follow the links in this table to see examples of the requests and responses.

Data Addresses	Read	Write Single	Write Multiple
Discrete Output Coils 0xxxx	FC0	FC05	FC15
Discrete Input Contacts 1xxxx	FC02	NA	NA
Analog Input Registers 3xxxx	FC04	NA	NA
Analog Output Holding Registers 4xxxx	FC03	FC06	FC16

What are data types?

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 16-bit unsigned integer (a whole number between 0 and 65535) register 40108 contains AE41 = 44,609 (hex to decimal conversion)

A 16-bit signed integer (a whole number between -32768 and 32767) AE41 = -20,927 (hex to decimal conversion that wraps, if its over 32767 then subtract 65536)

A two character ASCII string (2 typed letters) AE41 = ® A

A discrete on/off value (this works the same as 16-bit integers with a value of 0 or 1. The hex data would be 0000 or 0001)

Register 40108 could also be combined with 40109 to form any of these 32-bit data types: A 32-bit unsigned integer (a number between 0 and 4,294,967,295) 40108,40109 = AE41 5652 = 2,923,517,522

A 32-bit signed integer (a number between -2,147,483,648 and 2,147,483,647) AE41 5652 = -1,371,449,774

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...

A four character ASCII string (4 typed letters) AE41 5652 = ® A V R

More registers can be combined to form longer ASCII strings. Each register being used to store two ASCII characters (two bytes).

What is byte and word ordering?

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.

AE41 5652 high byte first high word first

5652 AE41 high byte first low word first

41AE 5256 low byte first high word first

5256 41AE low byte first low word first

What is a Modbus Map?

A modbus map is simply a list for an individual slave device that defines

what the data is (eg. pressure or temperature readings)

where the data is stored (which tables and data addresses)

how the data is stored (data types, byte and word ordering)

Some devices are built with a fixed map that is defined by the manufacturer. While other devices allow the operator to configure or program a custom map to fit their needs.

What is the difference between Modbus ASCII and Modbus RTU?

The difference between these two modes is explained here.

What are extended register addresses?

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 Master PCs) were written with the 40001 to 49999 limits and cannot access extended registers in slave devices. And many slave devices do not support maps using the extended registers. But on the other hand, some slave devices do support these registers and some Master software can access it, especially if custom software is written.

How does 2-byte slave addressing work?

Since a single byte is normally used to define the slave address and each slave on a network requires a unique address, the number of slaves 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 master and the slaves would all be required to support this modification. Two byte addressing extends the limit on the number of slaves 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.

How can you send events and historical data?

Enron Modbus includes commands for moving events and historical data..

What is Enron Modbus?

Enron Modbus is a modification to the standard Modicon modbus communication protocol developed by Enron Corporation.

See Enron Modbus for details.

Ethernet rules closed-loop system by Wesley Cole , John Eidson

The enterprise tool picks up speed and moves to the plant floor.

Traditional process control systems have used programmable logic controller (PLC)-based centralized control techniques to implement closed-loop control applications. Packet-based networks with collisions, such as Ethernet, are generally considered too slow and unreliable to safely handle closed-loop control.

Today, various fieldbus technologies and the ability to inexpensively place significant computation capability at the transducers allow control applications to be implemented using distributed techniques. This distributed function provides increased capacity, relieves computational and communication bottlenecks, and generally provides more flexibility in system design, modification, and expansion.

In a traditional process control system, the PLC polls the sensors and directs the actuators. The PLC processor, based on the control algorithm's execution characteristics, determines the time behavior of the system. In a distributed system, the time behavior is determined by the time behaviors of the application execution characteristics on the local processors, the local protocol stacks, and the communication network. A distributed system provides true multiprocessing and therefore the potential for improving computational throughput and synchronization characteristics of the system.

In implementing distributed systems, the process control industry has developed a wide range of communication networks. The computer industry has also provided a range of networks for the general distributed computing environment, with Ethernet being the most pervasive at the present time. Traditionally, Ethernet has not been used in control environments; it is found within the enterprise levels of process control and is increasingly being coupled to lower-level control functions. Advertisements for field-level products using Ethernet are beginning to appear in trade publications.

The use of general computer networks in field-level control will require some modification of techniques normally used in real-time systems. The computer industry has developed a number of distributed system techniques that will be useful in control. In particular, there is an increasing amount of literature on the use of real-time clocks in distributed systems.

Clocks are found at the PLC level of current process control systems. However, time synchronization at the device level is generally limited to timers and time ticks distributed over the network from a PLC. Let's explore the use of true real-time clocks at all levels of distributed closed-loop control systems.

Event or data driven?

In an event-driven system, it is important that the occurrence of an event be made visible in a reliable and timely manner. The order of events and their time relationship to the real world must be preserved. For events, time accuracy and distribution latency are the prime timing considerations. Alarms, state machines, and device commands are typical control structures using event mechanisms.

In a data-driven system, such as continuous closed-loop control, the real-world time relationship of successive data points must be preserved. Distribution latency (delay) must be such that the response times and stability requirements of the loop are not left unmet. The system throughput must be adequate to process and distribute the data.

In distributed control systems, each node must explicitly deal with synchronization issues. Messages without time stamps, when passed between nodes, can implement order, but not time specification. If time specification is to be imposed, then at least some of the nodes must have access to a clock. For closed-loop control, it is imperative that control algorithms are provided with the correct sampling time information for each of the control variables.

Provide the time

There are several ways to provide the sampling time information required by control algorithms like the widely used proportional-integral-derivative (PID) algorithm.

Polling of the sensors by the node implementing the control algorithm is commonly used today. The polling is normally periodic as seen by the polling node. The time error in polled systems is the departure from strictly periodic time, termed time jitter, inherent in various components of the system.

The main sources of this jitter are the communication protocol stack and the operating systems of the nodes. In the case of the protocol stack, this jitter results from queuing processes and parsing protocol headers.

Operating system time jitter arises from internal operations such as context switching and servicing software-maintained timers and clocks. With a carrier-sense multiple access (CSMA) protocol stack, such as Ethernet or LonTalk, this jitter can be important and is usually not known by the algorithm. However, even in non-CSMA stacks, such as controller area network (CAN) or Foundation fieldbus, care must be taken that operating system and application code jitter is negligible, as this jitter can be comparable to the jitter in a CSMA network.

Since there is no way to measure this jitter for each packet, there is no way to correct for jitter in simple, polled systems. A common variation on this theme is for a central node to distribute "ticks," which other nodes use to synchronize sampling. These ticks are subject to the same jitter problems as polling. In polled systems, control algorithm computations can only assume that the data was sampled at the poll times.

Another alternative is to make the entire distributed system operate synchronously. This has been done by running all the communications and computations on an enforced time-slice schedule. When run using a CSMA protocol stack, such a system can eliminate collision jitter, since by definition there is no contention for the network.

This type of setup uses synchronized clocks to enforce the schedule so data can be time stamped. Time-slice systems based on token rings or their equivalent, rather than on synchronized clocks, will have uncorrected time jitter comparable to polled systems.

The alternative presented here is to provide all nodes in the distributed system with accurately synchronized clocks. With such clocks, sensor data can be time stamped and control algorithms can use these time stamps to correct for the sample timing errors resulting from computational, operating system, and protocol stack jitter and delay. The accuracy of these clocks will determine the effectiveness of the corrections. To be effective, nodes must have hardware support for generating time stamps based on appropriate transducer control signals. Such systems can use CSMA protocols provided the clock synchronization is adequate.

As a side benefit, time stamps provide a method for detecting and correcting for missing or out-of-order data. Both missing and out-of-order data are possible in networked distributed systems, especially if routers are present. However, when CSMA networks are used under the same conditions (number of nodes and network traffic) as other fieldbus networks, the occurrence of missing and out-of-order data can be made rare and can be corrected in the control algorithm.

Synchronize your clocks

There are a number of techniques in use for synchronizing the clocks in a distributed system. A central time server is one possibility, but it introduces delays and excessive message traffic. For systems with more than a few nodes, a better choice is for each node to have a local clock participating in a synchronization protocol among the nodes.

The computer industry uses protocols such as the network time protocol (NTP) for clock synchronization among PCs and workstations. NTP is based on message exchange and produces accuracy on the order of a few milliseconds over Ethernet networks. To attain better accuracy, some sort of hardware assistance is required. Systems exist that produce accuracy of 10 microseconds.

We have experimented with clock synchronization based on hardware-assisted detection and recognition of special network packets for both Ethernet and LonTalk protocols. Synchronization accuracy is measured by recording the differences in the time stamps marking the occurrence of a series of mutually visible events as determined by the local clocks in two nodes.

Figure 1 is a histogram of these differences for two nodes communicating using the Ethernet protocol and demonstrates synchronization accuracy on the order of 20 nanoseconds. Figure 2 is a histogram of these differences for two nodes communicating using the LonTalk protocol and demonstrates synchronization accuracy on the order of 100 nanoseconds.

In both cases, this synchronization was obtained with one packet per second devoted to the synchronization algorithm. Except during the start-up phase of the algorithm, the number of synchronization packets per second is independent of the number of clocks being synchronized. The accuracy differences between the Ethernet and LonTalk implementations are due primarily to the differences in the network bit rates-10 Mbps for Ethernet and 1.2 Mbps for LonTalk.

The key benefit of this clock synchronization method is increased accuracy. While millisecond accuracy obtainable by conventional methods is adequate for many closed-loop control and monitoring applications, the submicrosecond accuracy reported here allows faster systems to be controlled in a networked environment.

Ethernet clocks the process

A simple control system was built to test the feasibility of implementing synchronized clocks and CSMA networks. The system is illustrated in Figure 3.

Both the tachometer and controller electronics were implemented using Motorola 68331 microprocessors. The communication mechanism is the unacknowledged datagram protocol on a 10base-T Ethernet. Each node contains a clock synchronized as described earlier.

The controller is a standard PID with trial coefficients determined by the Ziegler-Nichols frequency response method. The system was not stable using these initial values and was manually altered to produce a marginally stable one. Using marginal stability enabled testing under conditions that maximized the chances of observing deviations introduced by sampling jitter and network degradation.

The system was operated both in a polled mode in which the controller requested samples and in a push mode in which the tachometer controlled the sampling time. The data was always time stamped based on the local clock in the tachometer. The controller could be configured to either use or ignore the time stamps when computing its output.

As expected from previous analysis, it was difficult, but not impossible, to induce noticeable degradation in the system. During the collection of the data, the packet load on the Ethernet was 25% of capacity as measured by a local-area network analyzer. In each case, 100 samples of these waveforms were collected. For each waveform, the root mean square deviation of the actual response from the mean value was computed as a percentage of the mean value. This calculation was done independently for the falling and rising portions of the square wave perturbation. The results are seen in the table below.

While more experiments are necessary to fully quantify these results, it appears that the settling time was better using the time stamp corrections.

Similar experiments were conducted in which packets were deleted to simulate network collisions or checksum errors with no visible degradation in performance. In all cases, the network packet load ranged from about 10% to 30% of capacity.

The only dramatic network-based interference produced was a result of bogus packets specifically addressed to a control system node. Such packets pass the usual Ethernet hardware filter and must be processed and rejected by the lower levels of the protocol stack, which steals processor cycles from the application. These experiments need to be repeated for controllers implementing notch filters and other algorithms that may show more sensitivity to the timing-induced phase or amplitude jitter.

Additionally, both the phase and amplitude noise introduced by time jitter should be studied, particularly that introduced by alternative algorithms and conditions. Further, evidence exists that clock usage in event-driven applications needs to be examined as well.

It's clear that the use of synchronized clocks in data-driven closed-loop control systems using Ethernet as the field bus is a viable solution. The ability to synchronize clocks to accuracy more than adequate for most control problems has been demonstrated on both the Ethernet and LonTalk protocols. The presence of these clocks allows algorithms to be corrected for the actual times of sampling, potentially eliminating computation, protocol stack, and communication time jitter.

Additional Information

Figures and Graphics

Figure 1. Time differences between two clocks using Ethernet communication

Figure 2. Time differences between two clocks using LonTalk communication

Figure 3. Test system block diagram

Figure 4. System response using Ethernet communication

PDF of "Ethernet rules closed-loop system"

A project to have a free ladder language in C. Generally, you find this type of language on PLC to make the programs of automation process.

It allows to realize little programs or bigger in an electric way.

This project is released under the terms of the LGPL licence.

GENESIS...

I decided to program a ladder language only for test purposes at the start, in february 2001. It was planned, that I would have to participate to a new product after leaving the enterprise in which I was working at that time. And I was thinking that to have a ladder language in thoses products could be a nice option to considerate. And so I started to code the first lines for calculating a rung with minimal elements and displaying dynamically it under Gtk, to see if my first idea to realise all this works. And as quickly I've found that it advanced quite well, I've continued with more complex elements : timer, multiples rungs, etc... Voilà, here is this work... and more : I've continued to add features since then.

FEATURES...

Classic Ladder is coded 100% in C. It can be used for educational purposes or anything you want... The graphical user interface uses GTK+.

The programs are splitted in sections (mains or sub-routines), in which you select a language. Two languages can be used in them: Ladder. Sequential (also known as grafcet). The following elements are available in the ladder :

Booleans elements

Rising / falling edges

Timers

Monostables

Counters

Compare of arithmetic expressions

Booleans outputs

Set / Reset coils

Jumps

Calls to sub-routines sections

Operate of arithmetic expressions

There is a full editor for the rungs of ladder and the sequential pages. When editing, use the pointer of the toolbar if you want only to modify properties, else select the element you want to place in the rung. Each variable can be associated to a symbol name that can be then used instead of the real variable name.

ClassicLadder can run in real-time (optional) with RTLinux v3, with RTAI and recently with Xenomai. It can run on little embedded platforms (no GTK interface dependance, and number objects to allocate for less memory usage).

HARDWARE SUPPORT / SCADA...

Classic Ladder can be used to drive real physical inputs/outputs: Direct port access (parallel port for example) Comedi drivers project Modbus/RTU distributed modules (Serial) and Modbus/TCP (Ethernet) A Modbus/tcp server is available that can be used to link with a SCADA software (like Lintouch).

REQUIREMENTS...

For using Classic Ladder as it is, you need : Linux and GTK2 librairies Windows (but with not all the features for real I/O access)

DOWNLOADS...

You can download here on SourceForge the last sources + executable + projects examples.

DOCUMENTATION...

Actually you should take a look at the only README file available, included too in the archive (and here the TODO list for future works). But, here you will found a nice little manual for using the sequential editor done by someone using classicladder: http://users.teledisnet.be/web/rlo05343/umanual/umanual_for_classicladder.htmlIf you don't know at all how work ladder, you can take a look here:http://www.plcs.net/contents.shtml

You can take a look at the following project using ClassicLadder in an adapted version: EMC2, used to control machine tools. They have written some documents, that some parts could be interesting even if if is not totally the same version.

MatPLC is a PLC-like program for Linux (PLC = Programmable Logic Controller), licensed under the GNU GPL.

We take advantage of the fact that we have an underlying operating system and use its features to make the MatPLC modular. One module could be executing mnemonics. Another module is a PID loop. A different module handles I/O, or logs to a database. (These modules all already exist.) The MatPLC then coordinates their workings to present a simple interface to the user.

Currently, we are in early stages: we have a solid core, mnemonics for logic modules (python or C can also be used), a signal-processing module which includes a PID loop, several I/O modules (including numerous industrial networks and an interface to the comedi project) and some simple HMI modules.

We are cooperating with the classicladder project project, which will provide stepladder and GRAFCET in an intuitive, point-and-click form. However, the interface between the two projects is not yet ready.