KB Controls is reader-supported. When you buy through links on our site, we may earn an affiliate commission. Read more in our disclaimer

Working with Cause and Effect Matrix Programming in TIA Portal

A detailed look at how to work with the new CEM programming language available in TIA Portal and the advantages of this new high-level programming language.

TIA Portal version 17 has been shipped with a new high-level programming language known as Cause and Effect Matrix, or CEM. In this article, we’ll look at the advantages of the Cause and Effect Matrix programming language and take a step-by-step look at how to get started with CEM in TIA Portal v17.

Advantages of the Cause and Effect Matrix Language

CEM makes it easy to program simple processes

The CEM programming language provides a visual and intuitive way to link causes with effects. This allows individuals without strong programming skills to create a program to control simple processes.

CEM makes it easy to debug programs

The visual layout of the Cause and Effect Matrix programming language makes it easy to debug. Anyone monitoring the program can visually see what causes are missing for a given effect without having to dive into the details of the program.

CEM is available on all modern S7 controllers

The Cause and Effect Matrix programming language is available on both the S7–1200 and S7–1500 controllers. This makes it a scalable solution that can be part of a standard company library.

CEM is backward compatible

Programs that are written in the Cause and Effect Matrix programming language compile into the same machine code as all other languages. For this reason, programs written with the CEM programming language can be downloaded to CPUs running older firmware.

CEM will be available for safety programs

In its initial release, the Cause and Effect Matrix programming language is only available to use in non-safe PLC programs. However, in a future release of the CEM programming language, it will be available to create safety programs.

I think that the most compelling use case for the CEM language is writing the safety program since most companies describe their safety system in terms of causes and effects. I’m very excited to see when this becomes available.

Cause and Effect Matrix Demo

In TIA Portal, I have created a new project and added an S7–1200 CPU to the project.

Next, I’ll add a Program Block. I have called the Program Block “Conveyor Control” and chosen to use the CEM programming language for the block. I click OK to create the block when the configuration is done.

Create the Conveyor_Control block

The block is created and the Cause and Effect Matrix editor opens. You can see that the top row contains the effects and the left column contains the causes. The block interface is the same as the interface for a block created in any other programming language.

CEM Editor

Block Interface

In this example, we will write a program to control a bi-directional conveyor that carries goods from a load position to an unload position.

The conveyor is enabled by pressing a toggle enable button. If the button is pressed when the conveyor is not enabled, then it is enabled. If the button is pressed when the conveyor is enabled, then it is disabled.

When the system is enabled, the conveyor can run. The conveyor can run in two modes; auto and manual. The mode is selected by an operator via a key switch.

In auto mode, the conveyor runs in reverse until it detects the carrier at the load position. When the conveyor detects that a part has been loaded to the carrier, it runs in the forward direction.

The conveyor runs in the forward direction until it detects the carrier at the unload position. When the conveyor detects that the part has been unloaded from the carrier, it runs in the reverse direction.

In manual mode, the operator can jog the conveyor forward until the carrier is detected at the unload position and in reverse until the carrier is detected at the load position. Jogging in both directions is done with a pushbutton.

Based on these requirements, the interface for the block is prepared as follows:

Block interface

Exploring Causes and Effects with System Enable

The first thing we will do is handle the enabling of the system.

To enable/disable the system, we will need two causes;

  • The first cause uses AND logic to determine if the enable pushbutton is pressed and the system is NOT enabled.
  • The second cause uses AND logic to determine if the enable pushbutton is pressed and the system is enabled.

Therefore, I have to add a second Cause to the Causes column. To this, I can click on the Add New button in the Causes column:

Add a new cause

Next, I’ll update the name of both causes to something more descriptive than Cause1 and Cause2. I’ve gone with Req_Enable and Req_Disable.

Update names of Cause

Next, we can choose the type of logical operation we will use with our Cause by clicking on the two red question marks inside the grey instruction boxes.

List of valid logical operations

In our case, we want to use AND logic for both of our causes.

Use and logic for both causes

Finally, we will invert the logic for one pin of the Req_Enable Cause and connect the tags to the instructions.

Invert pin of AND operator
Tagged up causes

You can see that the use of logical operations and inversion allows you to create powerful expressions for causes in a system.

Next, we will define the Effect of the system enable action. In this case, the instruction will be an assignment operator (‘=’) executed on the o_CNV_Enabled output of the block.

Define the Effect

Now, we have to define the relationship between the Cause and Effect. You can do this by clicking on the intersection squares between the Cause and Effect.

Define relationship between Cause and Effect

When you double click on the intersection point, a pop-up appears allowing you to define the relationship between this cause and this effect. For the enable cause, the relationship is a SET (‘S’) action

Select action

For the disable cause, the relationship is a RESET (‘R’) action.

Disable relationship

Exploring Action Groups with Manual Control

In this section, we will program the manual control of the conveyor and learn how to create action groups, which link causes together in a logical way.

To start, let’s add the required causes to our program.

Add additional causes

Next, we’ll add two new Effects — run motor forward and run motor backward.

Define causes to run motor

Finally, we have to create a relationship between the causes and effects. Unlike the previous example, we want to have four causes active before we activate the effect.

We can accomplish this using action groups. To create an action group, double click on the intersection between a cause and effect, select the N (non-permanent) action and define a new action group which requires 4 out of 4 causes to be active to have an effect:

Define a new action group

In the editor, you see that the action group is created and shown in yellow. This is a warning that the group is not correctly configured.

Action group is not correctly configured

Now when you configure the next intersection, you can specify that this cause is part of the previously configured action group:

Specify cause as part of previously configured action group

Repeat this for all causes that should be part of the Run_Fwd effect and configure a new action group for the Run_Rev action group.

Finished logic for manual control

Exploring Intersection Columns with Automatic Control

Next, we want to program the automatic control of the conveyor. With automatic control, we have a completely different set of causes that create the same effect.

To have two sets of causes driving a single effect, we can add an intersection column to the effect column. To do this, right-click on the effect and choose Add intersection column

Add an intersection column to an effect

This creates an additional column where causes can be mapped to an effect, effectively providing OR logic for an effect.

New intersection column

Fill in the causes for running the conveyor forward in automatic mode and repeat the same for the Run_Rev effect.

Update logic with new intersection columns

Exploring Instructions with an Off Delay

The conveyor begins to run in the other direction when a part is loaded to or unloaded from the carrier.

We don’t want to begin running the conveyor as soon as the part is removed from the carrier. We want to give the operator that is loading parts a chance to place the part correctly in the carrier and we want to give the operator that is unloading parts a chance to get their hands clear before the carrier starts moving away.

Therefore, we will introduce a time delay to the Part_Pres cause and the Part_Not_Pres cause.

To do this, we can simply drag one of the Timer Operation instructions from the CEM Instruction list onto the desired Cause.

Add an instruction to the cause

The instruction is added and we can configure the delay on time for the instruction.

Finally, we can repeat the same process for the Part_Not_Pres cause:

Delay on for part not present cause

Monitoring CEM Blocks

Download the program to the PLC and monitor the block.

In the Effects row, we can see that the conveyor is not enabled:

Conveyor is not enabled

In my program, I have toggled the input i_PB_Toggle_Enable to enable the conveyor:

Conveyor is enabled

Now, if I want to run the conveyor forward, I can easily see which causes are missing:

Missing causes to run conveyor forward

In my program, I can toggle the missing causes to get the conveyor to run forward:

Run conveyor forward

As you can see, it's very easy to debug programs written in the CEM language since it is such a visual programming language. Almost anyone can monitor this program to understand what causes are missing to create the effect that they are looking for.


The Cause and Effect Matrix programming language is a new, highly visual programming language that’s included in TIA Portal v17.

Because it is highly visual, it is easy to create and debug programs with simple logic where there is an obvious relationship between causes and effects.

I think that the CEM programming language is a wonderful addition to any PLC programmer’s toolbox for programming simple logic. However, I don’t believe that a complex machine can be programmed exclusively using CEM since the instruction set is limited and the layout of the language is cumbersome.

Where I do see the potential to use CEM is with safety programming where safety causes have an obvious effect and I’m excited to see the CEM programming language released for safety programming.

PLC Programming Bootcamp

Learn how to write, test, and simulate your first PLC program for free.

Get Started

Related Content