KB Controls is reader-supported. When you buy through links on our site, we may earn an affiliate commission. Read more in our disclaimer
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.
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.
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.
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.
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.
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.
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.
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.
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:
The first thing we will do is handle the enabling of the system.
To enable/disable the system, we will need two causes;
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:
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.
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.
In our case, we want to use AND logic for both of our causes.
Finally, we will invert the logic for one pin of the Req_Enable Cause and connect the tags to the instructions.
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.
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.
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
For the disable cause, the relationship is a RESET (‘R’) action.
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.
Next, we’ll add two new Effects — run motor forward and run motor backward.
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:
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.
Now when you configure the next intersection, you can specify that this cause is part of the 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.
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
This creates an additional column where causes can be mapped to an effect, effectively providing OR logic for an effect.
Fill in the causes for running the conveyor forward in automatic mode and repeat the same for the Run_Rev effect.
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.
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:
Download the program to the PLC and monitor the block.
In the Effects row, we can see that the conveyor is not enabled:
In my program, I have toggled the input i_PB_Toggle_Enable to enable the conveyor:
Now, if I want to run the conveyor forward, I can easily see which causes are missing:
In my program, I can toggle the missing causes to get the conveyor to run 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.
This course introduces you to the S7 series of PLCs and the STEP 7 programming environment for S7 PLCs. It is an ideal first step for anyone who wants to become a controls or automation engineer or an industrial technician that wants to improve their knowledge of PLC hardware and programming.
In this tutorial, I provide you with a complete, step by step guide for integrating SINAMICS drives in TIA Portal projects including how to commission the standard and safety features of SINAMICS drives in Startdrive, how to integrate and control SINAMICS drives in your TIA Portal projects using standard telegrams and blocks, and how to control and visualize the status of SINAMICS drives in a WinCC HMI application.
In this post, we learn how to use OPC UA to communicate between two PLCs by setting up an S7-1500 as an OPC UA Server with a dedicated server interface and user authentication.