Part 10 - Understanding IO Hardware (using EtherCAT and IO-Link)

Video: https://youtu.be/zQwiBeDbDcM

#PLC #TwinCAT3 #Beckhoff #IEC_61131-3 #Hardware #Networks #Redes_Industriales #Industrial_Automation

🔙 Previous Part | Next Part 🔜

↩️ Go Back

Table of Contents:

A) Objectives

Hello!!
We finally reached the part of the tutorial that I know many of you have been looking forward to:

• I/O - short for input and output

So far we've only been talking about software but now we will finally look a little bit at hardware.

In most cases when working with PLCs and control systems you want the system to interact with the world in some way.

This can be from:

• the simplest case with just a few sensors for temperature and detection of whether a door is open or closed (and maybe opening or closing of a relay)
• to an advanced case which includes thousands of sensors, motion control of motors, and robots and vision systems using cameras.

Personally it was when the PLC software I wrote was integrated with hardware that I really felt the full power of PLCs.

Enough talk, let's get started!

B) Introduction to I/O fieldbuses

When talking about inputs and outputs, you generally talk about having sensors to gather information about your surroundings, and actuators to interact with your surroundings.

Examples of sensors might for example be:

• gas sensors
• flow meters
• leakage detectors
• distance sensors
• temperature sensors
• movement detection sensors
• humidity sensors

MORE INFO ABOUT SENSORS

Examples of actuators might for example be:

• conveyor belts
• motors in general
• heaters
• coolers
• lasers
• pumps
• robots.

MORE INFO ABOUT ACTUATORS

Now our PLC needs a way to interact with all these different objects.

For this it requires something referred to as a [[fieldbus]], which is an interface that connects the PLC to all these sensors and actuators.

A [[fieldbus]] is a name for an industrial computer network used for real-time distributed control. A [[fieldbus]] can be implemented in a wide variety of ways and there are many different ones.

A few of the more popular ones are:

• [[Profinet]]
• [[CC-Link]]
• [[Modbus]]
• [[Powerlink]]
• [[EtherCAT]]
• [[EtherNet/IP]]
• [[CANopen]]

Each one has its own set of disadvantages and advantages. For each there is generally one or more companies backing them up and the companies often have economical incentives to do so.

In this part I will focus on talking about [[EtherCAT]], as this is the de facto [[fieldbus]] in Beckhoff PLCs. It was invented by Beckhoff, and the real-time drivers for it are per default included in every Beckhoff PLC.

Even though we will only cover [[EtherCAT]] in this tutorial, I'd like to point out that it's possible to do virtually all [[fieldbuses]] that are in existence with TwinCAT. There are both hardware modules and software real-time drivers to do all kinds of field buses so you are not restricted to EtherCAT.

EtherCAT was invented by Beckhoff and is thus the natural choice when working with TwinCAT 3 It also has the tightest integration into TwinCAT 3 of all the fieldbuses.

With this being said I think it's time for a short introduction to fieldbuses in general, and EtherCAT in particular.

B.1) Introduction to EtherCAT

An [[EtherCAT Network]] constitutes of one [[EtherCAT Master]] and one or more [[EtherCAT Slaves]].

The [[EtherCAT Master]] is responsible for sending out [[EtherCAT Telegrams]] that are intercepted by each [[EtherCAT Slave]].

Each [[EtherCAT Slave]] reads the data sent to it, and also provides its own data to be transmitted back to the [[EtherCAT Master]].

While the [[EtherCAT Master]] is entirely implemented in software and can be implemented using the standard networking hardware you find in any computer, such as your PC.

Each [[EtherCAT Slave]] requires a special chip called the [[EtherCAT Slave Controller]].
Note: Do you remember this guy from [[Part 6a - Function blocks & interfaces (IEC 61131-3)]]?

Although the requirement that we need special hardware in each [[EtherCAT Slave]] on one side is a big disadvantage, it's also one of the reasons we can get extremely fast cycle times on the bus.

I've personally run EtherCAT in cycle times of 100 microseconds, but I know it's possible to run even faster than this.

Now I will demonstrate how a typical cycle in an [[EtherCAT Network]] could look like.

B.1.1) EtherCAT Network (example)

Imagine we have our PLC with an integrated [[EtherCAT Master]] software stack.

This will talk to one or several [[EtherCAT Slaves]]. The [[EtherCAT Slave]] is just one component of a device that gives us access to the sensors and actuators.

The [[EtherCAT Network]] can consist of many [[EtherCAT Slaves]].

Some of them might be part of:

• a very basic device that only does simple digital inputs and outputs,
• while others might be part of a very complicated device such as a robot and a drive for motion control.

Each [[EtherCAT Slave]] will have a certain amount of bytes for input and output data.

The input and output in these terms is from the perspective of the [[EtherCAT Master]]. This means that:

• input data will be data provided from sensors,
• output data is data to actuators.

The data for input and output is depending on the application of where the [[EtherCAT Slave]] is being used.

Now let's imagine that the [[EtherCAT Telegram]] is like a train.
This train carries output data that will be transmitted to the [[EtherCAT Slaves]].

This data has just been set by the PLC internally by the software that we have written.

What happens now is that the train stops at the first station (the first [[EtherCAT Slave]]),

and puts a certain amount of data into the [[EtherCAT]] device. This data can for example be used by the [[EtherCAT slave]] device for the actuators that are connected to it.

At the same time the train is picking up whatever data the [[EtherCAT]] device has ready for it, which corresponds to the sensor data.

Then the [[EtherCAT Telegram]] moves to the next station (or [[EtherCAT Slave]]) and unloads output data and loads input data on the telegram.

This is again repeated for all [[EtherCAT slaves]].

After visiting all [[EtherCAT slaves]], the train returns to the PLC and returns all the input data from the whole [[EtherCAT Network]] to the PLC, which can be used in the TwinCAT3 software.

You can simply see this whole setup as a brain which corresponds to the PLC, with nerves corresponding to sensors and muscles corresponding to the actuators.

The [[EtherCAT Network]] can run really fast. Running at speeds less than 100 microseconds cyclically with minimal [[jitter]] is not a problem.

B.1.2) EtherCAT terminals (Linking Hardware)

When you will start working with hardware you will most likely encounter some form of [[fieldbus terminals]] or boxes.

B.1.2.1) EL1004 terminal (4 digital inputs)

One example of this is the Beckhoff [[EL1004 terminal]], which is a four channel digital input.

Digital means to detect whether we have 24V on an input or not. So basically just detection of ON or OFF, for example a door switch or limit switch.

Each one of Beckhoff's EL-terminals has an integrated [[EtherCAT slave controller]], so it can do [[EtherCAT]] communication.

It's this [[fieldbus]] communication that we are using to get the status of the inputs.

B.1.2.2) EL2004 terminal (4 digital outputs)

There are also terminals to do the opposite, that is, when you want to actuate something with a 24V output.

The equivalent for this is the [[EL2004 terminal]], which houses four digital outputs.

Beckhoff are not the only ones that are manufacturing fieldbus devices with EtherCAT capability. There are many others.

B.1.2.3) IFM AL1330 IO-Link master (4 IO-Link channels)

One of my favorite devices is one manufactured by the company IFM.

This is slightly more advanced than the two previous ones as this supports four channels of [[IO-Link]].

B.1.2.3.1) What is IO-Link?

[[IO-Link]] is a bi-directional point-to-point industrial communication networking standard for connecting digital sensors or actuators.

This is based on a serial protocol so it can exchange a vast set of data between the terminal and the sensor.

These are just a few examples of [[fieldbus]] devices, there are thousands of other out in the wild.

B.1.2.4) How to Link Software to Hardware? 🔍

To actually use [[fieldbus]] devices in TwinCAT, you have to link the software to the hardware

For inputs this is defined with a name of the links, %I* characters and the data type of the inputs.

Compiling will give you instance variables in the process data image that you can link to the hardware.

For outputs it's done the same way with the only difference that you use %Q* instead.

Compiling the code will give you instance variables in the process data image that you can link to the hardware.

Once this is done you can freely use these variables in your code.

The final step we need to do to close the loop, is to link the variables to the actual hardware. All the real-time capable hardware is presented in the I/O object in the TwinCAT solution. This will require an [[EtherCAT master]] in where we can define our terminals.

In this case the [[EL1004]] and [[EL2004]]. These two objects represents the actual physical devices.

The only thing that's left for us to do is to link our process data variables to the hardware.

• In this case inputs are shown with a yellow icon on both sides, so in our code and in the I/O tree.

• While outputs are shown with a red icon on both sides.

I'll show how the linking is done shortly.
It's that easy!

Alright, I think that's enough talk. Now it's time to look at some actual hardware.

C) Demo: Hardware connections setup

It is time for playing around with a little bit of hardware.

For this setup I will show you some of the stuff that we're going to use today.

C.1) Beckhoff IPC (CX5140)

First of all, we're going to use a Beckhoff PLC, in this case a [[CX5140]].

This is a PLC I've been using for for many years and I've had it here in my home for learning and understanding stuff.

It is basically a standard PC, that's the way I see it. I mean it has:

• a Intel CPU,
• it has a motherboard,
• it has the standard DDR3 or DDR4 memory
• It has network ports.

Read more here

Everything that you would expect if you just went to the computer store and bought a PC.

The difference that this is in industrial casing. So it's made for an industrial environment.

First of all the casing is quite sturdy. It's made to be running 24/7.

Read more here

There's other adjustments like it's using 24V for the power so you supply this with 24V which is an industrial standard.

C.2) The E-Bus and the EL-terminals

Other than that we have the [[EtherCAT slaves]] here, so these are the Beckhoff EL-terminals.

You basically have a terminal for any type of sensor. You have:

• digital inputs,
• digital outputs,
• analog inputs
• analog outputs
• safety terminals
• etc

I mean there's so many different of these terminals. Each and one of these terminals has an [[EtherCAT slave]] built into them, so that's how the PLC talks to these terminals.

The way the Beckhoff PLC does that is by a proprietary interface called the [[E-bus]].

Tabla 1: Comparación entre E-bus y K-bus

You basically wire up your sensors here and then each terminal takes care of providing that information to the [[EtherCAT master]] so we can get it cyclically in the process data which I will soon show.

C.3) A Stepper Motor with an Encoder (EtherCAT Slave)

In this example I also have lots of wires here as you can see and what I've wired up here is a motor. It's a motor with an encoder.

So, this terminal here is basically a drive for a stepper motor in this case.

It's quite impressive that you can actually have so much electronics in such a tiny tiny casing.

C.4) Port1: Ethernet Connection

What I want to mention now is that we have two network ports here.

One is used to connect this PLC to the local network here in my home.

This is just so that we can read the variables from the PLC, so we can upload new software, so we can do [[remote desktop]].

I mean again, this is a standard PC more or less so it's running the Windows operating system and because it's running the Windows operating system it means that we have all the standard services that you would expect. In this case you know you have remote desktop, the [[RDP protocol]] for example.

But you also have the whole [[TCP/IP stack]] in Windows which is all accessible for this network port.

C.5) Port2: EtherCAT Connection (with IO-Link Master)

For the second network port I have loaded a real-time network driver for [[EtherCAT]].

So this port here we will use for [[EtherCAT]] communication. What this guy is connected to is this [[IFM IO-Link master]].

[[IO-link]] is a protocol to communicate with sensors.

So it's a special protocol just to get on the lowest level on the factory floor, that is sensors and actuators.

This guy has an [[EtherCAT slave]] just like all of these terminals.

This is the way that we can communicate from the [[EtherCAT master]] to the [[EtherCAT slave]].

But at the same time as this is an [[EtherCAT slave]] then it's also an [[IO-link master]].

So an [[IO-link master]] can talk with [[IO-link slaves]] and [[IO-link slaves]] are the low-level sensors and actuators.

In this case we will use a [[distance sensor]] so this is a laser distance sensor.

I think that it has a range from three centimeters to two/three meters

Note: In this case both are IFM but it doesn't have to be. [[IO-link]] is a standardized protocol and there are many many manufacturers using [[IO-link]].

Why I want to use this particular unit?
It is because I want to show [[IO-link]], because I think [[IO-link]] is a very capable protocol. It provides much more stuff than the usual digital inputs and digital outputs, they're not very exciting. You actuate 24V or you read 24V, while these are are a little more fun.

This is an [[IO-link]] [[EtherCAT slave]] so it means that the communication here is [[EtherCAT]] in and then you can connect the next [[EtherCAT slave]] in the chain.

Note: Consider we can use different network topologies,

With that being said I think it's time to write some software to get this sensor to talk to our PLC.

D) TUTORAL 21 - How to link IO with EtherCAT and IO-Link //FILE -->O5D100 ✍️

Now it's time for the best part of the day, a little bit of programming.

What I've done here is that I've created a completely empty and new project.

In this project we will add the hardware communication so that we can talk to our [[telemeter sensor]], in this case the [[IFM O5D100]]...

D.1) Step 1 - How to connect to the PLC 🔍

I'll simply gonna start with connecting to the PLC because previously, so far we've only been running everything locally on on our virtual machine.

Right now we will run on the PLC and to do that we need to do something called an Ams connection, so that we can talk ADS with the PLC.

Note: I will talk more about ADS in a future part of this tutorial. Right now it's only important to know that we have to connect to the PLC.

To connect we need to go to this little icon in our development environment.

The go to Router -> Edit Routes,

To do connections to any other PLC you have to go through this window. Click "add",

And enter the IP-address of the PLC,

Note: We can also do a broadcast search.

Click on Refresh Status,

The PLC shows up, gives some information about what version of TwinCAT, what operating system version is running on the PLC and other things.

But just click "Add route",

And enter the administrator password for the PLC, in this case it's "1", the standard default Beckhoff password.

Then we have a connection here. We can close this window.

Now we can suddenly select the PLC as the target, so the PLC was the one that I showed before this [[CX5140]].

So after we select the PLC, what we're gonna do first is that we're gonna do a scan of the inputs and outputs.

D.2) Step 2 - How to do a Scan I/O Devices 🔍

This is the first time we're going to do a scan of the inputs and outputs. Which basically just detects "is there anything connected to this PLC?"

You do that by right clicking "Devices", and select "scan".

This gives a warning "hint not all types of devices can be found automatically", which is true. In this case it will find it automatically. Select "ok".

Note: What happens when we click OK is that right now on the PLC it is looking for all network adapters, what drivers are connected to these various network adapters. Default TwinCAT will assume that you want to run EtherCAT because again this is the default fieldbus on the TwinCAT 3 PLC's.

And these are the devices found,

Here I know the COM-port here, that's an [[RS232]] port on the PLC.

But we are not going to use that, so we don't need that selected.

Now, there's two EtherCAT masters here.

The first one here, that's usually the E-bus terminals.
So it's all the terminals to the right of the PLC. You know, all these EL-terminals that we had attached.

But, we don't want these because we wanna use the IFM IO-link master, which was connected in a separate EtherCAT master that was going from the network adapter.

So we don't wanna use this one,

We just wanna use the one that's connected to this network adapter.

So it is just the cable going out from the PLC. Select "ok",

Then"scan for boxes"...
Note: "scan for boxes" is basically "Hey! Do you want me to search for EtherCAT slaves?" That's basically what it's asking. Select "Yes"

Activate free run. This is not so important now. Just select "yes".

What we can see here is that we have the IFM IO-link master detected, that's this AL-1330.

So again, the AL-1330...it's this guy that I showed you before.

It has been detected!!

We can go here,

and here we see all kinds of stuff about [[IO-Link]]....

We see:

• some default inputs,
• we have some state for the EtherCAT slave.

So if you want to have a [[Profinet]] driver (from Siemens) for example.

You can create an [[Profinet]] controller here.

So Beckhoff have provided real-time drivers for various fieldbuses that you can use and you can link these guys to any of the available network adapters that you have installed that are supported by this driver.

D.3) Step 3 - How to configure the IO-Link port 🔍

But what we're going to do now is that we basically have to tell this IO-Link Master that: "Hey, I have this type of sensor connected to port number one",

because the IO-link slave, in this case the distance sensor, was connected to the first port of the IO-Link Master.

So we have to tell this guy that "Hey, there's something connected to this port".

To do that we have to go here to slots,

And here we can configure the different channels

So again if you look at this guy you see it has four different channels,

so we can connect four different sensors or actuators to this IO-link master.

Note: There's other variants with eight or even I think 16 ports if you want that but yeah, this one supports four.

The way you do that is that you go to the first channel,

and then you have to define how many bytes are going in and out, so how much process data basically is going from the sensor.

So we can define both in bytes and out bytes.

Every IO-link slave that's connected to an IO-link master has a predefined set of process data.

So it can be one byte, it can be two bytes, four bytes or I think up to 32 bytes per sensor.

D.3.1) Distance Sensor Documentation Breakthrough (O5D100)

To know what our guy is handling, so our IO-link slave I've opened up the documentation for the sensor.

So we can download the PDF for its documentation.

Note: You're going to read many many type of documents like this when you work with PLC software development. You're going to look at lots of documents for sensors and so this is just something you will have to get used to.

In this case I think IFM, their documentation is really good. I usually just look...and we just want to find how many bytes does the process data define.

Here we can see process data input. And it's a total of 16 bits,

so it's two bytes of data whereas 12 bits is the distance.

Here we can see the value range is 5 to 200. That's the value range for our distance sensors.

We can measure stuff between 5 and 200 centimeters.

But we also get an extra bit here, and this extra bit is quite good to have actually this guy,

because it tells us whether the value range is correct or not so basically whether we have a distance below 100 cm (this is the factory default). And if that is the case, we can trust the measurement.

Summary: We found that the process data input uses two bytes. Then we know we can go back to TwinCAT.

D.3.2) Deactivate IO-Link channels and Picking the required Process Data in TwinCAT

From the table, we can say that we don't need 32 bytes, or 16 bytes, or 8 bytes. The lowest one is four bytes, which is fine for our case,

Then we'll just say "hey we want four bytes", but we're just gonna skip two of those. We're just gonna take two of these bytes.

And we can also deactivate the channels on the IO-link master, so we will do that first.

We'll select the IO-link channels.

So first "delete",

It looks like this:

Then select "deactivated",

And finally it looks like this:

We do this for channels two, three and four,

And for channel one we do a delete,

And we say "Hey, use four bytes".

And the interesting thing is that what happens here is that we get this four bytes.

So we say for the first channel we're gonna have four bytes of data.

For example, if you had another sensor here, let's say we had some power measurement device. Usually that provides you much much much more data than two bytes. Then you would want to.. maybe use 32 bytes. So then you would define "Hey this is a 32 byte channel"

Then you would get another channel here with 32 bytes of data,

but right now for this part of this tutorial, I will only show you this simple distance sensor.

D.4) Step 4 - Get the Sensor Process Data into ST Code 🔍

Next what we need to do is to write our code to actually get this data.

So in the end of the day what we want is...we want the current  distance, and we want to know whether we can trust the data or not, whether it's valid or not.

We want those two data points...

D.4.1) Making a FB for the Sensor

So when I start coding... in this case we want to have a function block for this, right? Because we want to put the related code for this particular sensor here. Let's just call it what the sensor is called, in this case the name of the sensor O5D100

We can simply just define what the inputs and outputs are for this.

In this case we just have the input bytes. For this demo I'm going to make it very simple and simply define that the input bytes are defined inside the  function block. I'll get to it so you you'll see what I mean.

Defining the Outputs of the FB

What we want out is the distance. So we can just call it nDistance
We can just write a comment that is in centimeters.

Note: the value range is in discrete values between 5 and 200 so it's not a floating number.

Then we want a boolean that we can call "bInValueRange"
And we can just say that true equals valid.

So we have defined what we want out from the function block.

D.4.2) Linking Bytes to Variables 🖥️

Now we need to link these bytes and convert these bytes to the distance value. We have to convert these two bytes into the values that we're interested in.

So first  start with declaring the two bytes. As I showed previously, to get to link the two bytes into our  program, we need to use this %I* operator.

So let's just call it aInputBytes. That's an  array with two bytes so array[1..2] of BYTE

But we want these guys to be linkable so that we can link them to these two bytes here,

so it's AT %I* which  means that when we compile this we're going to have two bytes in the process  data image that we can link to the hardware

but before doing that I need to create an instance  of this function block.

I need to instantiate it in the memory so that we have  an actual instance of this object.

Simply create it like this,

Copy PLC Code:

PROGRAM MAIN
VAR
	fbO5D100 : FB_O5D100;
END_VAR
---------------------------------------------------------------------
fbO5D100();

And compile. So I'll rebuild.

We get this message,

What TwinCAT says here now is "Hey, this EtherCAT master it needs at least a variable linked to any program  that's running in a task", and the reason for this is that the EtherCAT master needs to have someone  that dictates how fast the EtherCAT master should send out the telegrams, right? Because there's  no reason to send EtherCAT telegrams faster than we run in our program. So if we have a task  that's running every 10 milliseconds then it kind of makes sense to run the EtherCAT master at  10 milliseconds, which means that we will have new data from the EtherCAT fieldbus every 10  milliseconds. So TwinCAT just says "Hey I have no idea how fast you want to run EtherCAT right now, could you please tell me how fast I should run EtherCAT?"

Let's recap. I have compiled the program now, and I have a main program. But we need to link the bytes, both to get the data so we...both so that we will get the data coming from the IO-Link slave but also so that the EtherCAT master knows how  fast it should run this task,

in this case our PLC task is running at 10 milliseconds,

so that's the speed of which [[EtherCAT]] is going to run.

Now that we have compiled our program we have this guy here,

Remember this?

Now we can click on this guy aInputBytes[1]

And click "Link to"

and we can link the first byte of the array to the first byte of the sensor, click "Ok"

We do the same thing with aInputBytes[2], then click "Ok"

And this is where the magic happens, right? Because if you come to think about  it now we just linked our variables in our code to the fieldbus, but we didn't have to write any code and this software to get the EtherCAT up and running.

I mean getting an EtherCAT master to work in TwinCAT is very easy.

Now we have these guys linked and we can also see it down here because you see you have these two arrows here,

that are indicating that "hey these two bytes are actually linked to something in the PLC code".

D.5) Step 5 - Convert the Bytes into Distance Values 🔍

Now  we have this linked in the PLC code,

the next step is that we need to convert these bytes, whatever  these bytes are into these values.

Here we need to go back to the documentation.

D.5.1) Separating the Bytes into Words

We can see that we have two bytes and the two bytes create one word, so 16 bits in total. But we're only interested in 12 of these.

The way I think about this is that I want to convert both of these bytes into a separate word and then we can do some bit shifting and moving  these bits around to the left and to the right to just extract the stuff that that we're interested in.

I mean there's there's many ways to do this actually, I'm just gonna show you one and it's probably not gonna be the cleanest and best way but it's gonna be one way that I just make up on the go here.

Okay, so we have two bytes, let's create a word for each and one of them.

So let's call it nWord1 and nWord2,

So a byte is eight bits. A word is 16 bits so there would be an implicit conversion here. I'd recommend you  to do an explicit conversion by saying TO_WORD .

Right now the way I think about it is that if.... the first byte looked like this then...

then the word will look like this now

Because we only use the eight first bits in the word.

D.5.2) Bitwise Shifting (IEC Operators) 🖥️

And the first thing I will do now is that I will simply...so first we have to make an assumption. One assumption I have to make is that this byte is the one that's reached the PLC first. This is the first byte, this is the second byte:

So what I want to do is that I want to shift the first byte eight bits to the left.
And then fill the second byte to the remaining place.

We can do that with something called SHIFT LEFT.

It's a bit wise left shift of an operand. It basically moves an n amount of bytes.

We do that by saying nWordOne is equal to...

It means that this should look like this now:

So we've shifted these eight bits to the left.

For the second byte we don't have to do  anything right now because what we want to do is that we want to OR this 1st byte with this 2nd byte while they're in their words to get the complete 16 bits that we're interested in.

And then we'll mask the last bit out.

Let's create a third word. Again this is not the cleanest code. This can probably be made much cleaner. What we want to do is that we want to create a third word and OR them. So we have "word one OR word two", and what that means is that if we OR them with each other they're gonna fill the missing "ones" because $(1$ $or$ $0)=1$

So it would look like this,

But we're not  interested in the last four bits to know the distance,

because these four bits don't hold any data except for the last bit that's interesting.

But we'll take that later so what we'll do now is that will shift everything four bits to the right, and get the distance bits only.

So nWordThree is equal to....

which means we're gonna end up with...

Which is exactly what we want so we'll end up with the value...the 12 bits that are interesting.

Now we need to convert this word to the integer, so we'll simply do a conversion,

What we forgot is this bInValueRange and  there's a very convenient way for us to get this single bit. If we look at the documentation we can see it it's in the second byte, so it's the first bit in the second byte.

The way you go  about it is that...so we have the second byte here that we can simply say that...

Copy PLC Code:

FUNCTION BLOCK FB_O5D100
VAR_OUTPUT
	nDistance : INT; // [cm]
	bInValueRange : BOOL; [TRUE = Valid (Within 100 cm)] 
END_VAR

VAR
	aInputBytes AT %I* : ARRAY[1..2] OF BYTE;
	nWord1 : WORD; 
	nWord2 : WORD; 
	nWord3 : WORD; 
	 
END_VAR
---------------------------------------------------------------------
nWord1 := TO_WORD(aInputBytes[1]);
// 1111_1111
// 0000_0000_1111_1111

nWord2 := TO_WORD(aInputBytes[2]);
// 1111_1111
// 0000_0000_1111_1111

bInValueRange := aInputBytes[2].0; 

nWord1 := SHL(nWord1, 8); 
// 0000_0000_1111_1111
// 1111_1111_0000_0000

nWord3 := nWord1 OR nWord2;
// 1111_1111_0000_0000
// 0000_0000_1111_1111
// ------------------- OR
// 1111_1111_1111_1111

nWord3 := SHR(nWord3, 4); 
// 1111_1111_1111_1111
// 0000_1111_1111_1111

nDistance := TO_INT(nWord3);

I think that's it, we are done...

It's not the most pretty code, but I think this will actually work. Well it depends whether we got the ordering of the bytes right.

D.6) Step 6 - Testing the Sensor

But I think this is enough to actually test the code. We will test the sensor with a few objects of mine.

We can see  as we move the sensor around, the values change,

If we get within 100 centimeters then the boolean becomes true,

I think it's really fun to  play around with hardware.

Final Words:
Well, we have now again reached  the end. Just as with most of the other things I've been talking about in this tutorial, what I've presented here is just a tiny tiny tiiiiiiny part of what I would like to talk about. This topic is really really REALLY big.

Anyway, I hope that you feel that you've learned  something new, and see you in the next part!

G) 💬 Summary (copy code 🖥️)

G.1) EtherCAT Basics

An [[EtherCAT Network]] constitutes of one [[EtherCAT Master]] and one or more [[EtherCAT Slaves]].

The [[EtherCAT Master]] is responsible for sending out [[EtherCAT Telegrams]] that are intercepted by each [[EtherCAT Slave]]. Each [[EtherCAT Slave]] reads the data sent to it, and also provides its own data to be transmitted back to the [[EtherCAT Master]].

While the [[EtherCAT Master]] is entirely implemented in software and can be implemented using the standard networking hardware you find in any computer, such as your PC.

Beckhoff Terminals

Tabla 1: Comparación entre E-bus y K-bus

Tabla 2: Comparación de Series de Terminales

G.2) IO-Link Basics

[[IO-Link]] is a bi-directional point-to-point industrial communication networking standard for connecting digital sensors or actuators.

This is based on a serial protocol so it can exchange a vast set of data between the terminal and the sensor.

[[IO-link]] is a protocol to communicate with sensors.

So it's a special protocol just to get on the lowest level on the factory floor, that is sensors and actuators.

This guy has an [[EtherCAT slave]] just like all of these terminals.

This is the way that we can communicate from the [[EtherCAT master]] to the [[EtherCAT slave]].

But at the same time as this is an [[EtherCAT slave]] then it's also an [[IO-link master]].

So an [[IO-link master]] can talk with [[IO-link slaves]] and [[IO-link slaves]] are the low-level sensors and actuators.

G.3) Example: How to setup a Distance Sensor (O5D100)

In this case we will use a [[distance sensor]] so this is a laser distance sensor.

Sensor Documentation:

Copy PLC Code:

PROGRAM MAIN
VAR
	fbO5D100 : FB_O5D100;
END_VAR
---------------------------------------------------------------------
fbO5D100();

Copy PLC Code:

FUNCTION BLOCK FB_O5D100
VAR_OUTPUT
	nDistance : INT; // [cm]
	bInValueRange : BOOL; [TRUE = Valid (Within 100 cm)] 
END_VAR

VAR
	aInputBytes AT %I* : ARRAY[1..2] OF BYTE;
	nWord1 : WORD; 
	nWord2 : WORD; 
	nWord3 : WORD; 
	 
END_VAR
---------------------------------------------------------------------
nWord1 := TO_WORD(aInputBytes[1]);
// 1111_1111
// 0000_0000_1111_1111

nWord2 := TO_WORD(aInputBytes[2]);
// 1111_1111
// 0000_0000_1111_1111

bInValueRange := aInputBytes[2].0; 

nWord1 := SHL(nWord1, 8); 
// 0000_0000_1111_1111
// 1111_1111_0000_0000

nWord3 := nWord1 OR nWord2;
// 1111_1111_0000_0000
// 0000_0000_1111_1111
// ------------------- OR
// 1111_1111_1111_1111

nWord3 := SHR(nWord3, 4); 
// 1111_1111_1111_1111
// 0000_1111_1111_1111

nDistance := TO_INT(nWord3);

🔙 Previous Part | Next Part 🔜

↩️ Go Back

Z) 🗃️ Glossary