Data blocks in TIA Portal

adam_lhadi

Member
Join Date
Feb 2022
Location
algeria
Posts
59
Hi everyone
i have uploaded some machine programs, what i noticed is that the programmer puts the inputs in a data block and work with this data block in the user program, and doing the same thing for the outputs
so, there is a data block for input and a data block for outputs

what's the benefits of this method or is it just a programing style for each programmer
also dedicating FCs or FBs one for inputs and one for outputs

kind regards
 
Last edited:
It's a very common way of mapping, often (generally beforesimulators were common), the I/O is mapped to internal memory this is usually in one or two programs that during simulation the call (s) to the blocks are disabled.
This means that the program can be simulated without the need for real I/O as without it calling the I/O may put the PLC into stop.
Also, many programmers automate the simulation by creating other program blocks to simulate things like valve operation or motors with feedback, this also applies to analogs.
It means that simulation blocks can be programmed so when a valve is operated spare timers are used to simulate the opening or closing of the valve before the valve limits are reached. Analogues can be simulated for example when a valve opens the simulation program increments the weight or level just as would happen in the real world.
When testing hase been completed, the simulation blocks are either deleted or the call to them disabled & the I/O mapping programs re-enabled.
Even with simulation programs this type of simulation is still used as simulators are generally clumsy to program the operations. Note many PLC's do not allow inputs to be written to in the program so mapping them gets round this when in simulation.
 
To expand on what @Rob... wrote:

Another benefit is that mapping the "physical" inputs and outputs allows changing which physical channel is used for a value, should the initial channel fail, by making a single change in the I/O mapping routine instead of finding every occurrence of the failed channel throughout the code.

Also, and I don't know if this is an issue with Siemens PLCs, but some PLCs run program scan tasks and I/O scan tasks asynchronously, so the value of an input could change between the start and end of a program scan. As I said, this may not be an issue with Siemens, but if someone has experienced a subtle bug because of this at some point in their career on other brands, then an I/O map could quickly become their standard practice.
 
To expand on what @Rob... wrote:

Another benefit is that mapping the "physical" inputs and outputs allows changing which physical channel is used for a value, should the initial channel fail, by making a single change in the I/O mapping routine instead of finding every occurrence of the failed channel throughout the code.

Also, and I don't know if this is an issue with Siemens PLCs, but some PLCs run program scan tasks and I/O scan tasks asynchronously, so the value of an input could change between the start and end of a program scan. As I said, this may not be an issue with Siemens, but if someone has experienced a subtle bug because of this at some point in their career on other brands, then an I/O map could quickly become their standard practice.


It depends how you read inputs and write inputs on Siemens. There was PIW an IW commands for analogs on old step7 (Same also for DI and DO IOs but them needed whole byte instead of bit).

P (periherial) was readed directly from card on program scan when needed.

TIA have same but syntax was differend on typing, maybe input:p.
 
Correct, you can read write input/outputs in Step 7 asynchronously by using the prefix P, so PIW, PQW, else read an write via IW and QW.

TIA portal uses the :p suffix. IW:p, QW:p.
 
For Siemens plcs the I/O data already exists in a data area - why copy it to another one? - for simulation you can modify the process image as required. PW/SFC14/15 will need simulation DB's


:whistle:
 
Hi everyone
i have uploaded some machine programs, what i noticed is that the programmer puts the inputs in a data block and work with this data block in the user program, and doing the same thing for the outputs
so, there is a data block for input and a data block for outputs

what's the benefits of this method or is it just a programing style for each programmer
also dedicating FCs or FBs one for inputs and one for outputs

kind regards


At some point I had code that would make most people jump out of a window.
I don't remember the exact details but I have a copy of the project somewhere still. As I recall had a udt fo digital inputs, one for analog inputs and one for digital outputs, all for S7-1200. The udt was instantiated in IO DB and then the physical inputs and outputs were mapped to the tags in the DB, in two FCs, one for inputs and one for outputs.

This structure was actually deployed on one machine :D and no more than a week later I wanted to reuse the structure in a new project and could not understand or rollow whatever it was I was trying to do, that was the end of that.

Someone out there is at risk of suicide if that machine to ever need troubleshooting.
 
A different view.
I have often worked for outfits where the hardware designers assign the I/O points to physical hardware.

So by making a DB for all the physical I/O, you can go ahead with writing your logic, without having to wait on the hardware guys. Then when the I/O has been assigned, you just map the physical to the logical.
 
For Siemens plcs the I/O data already exists in a data area - why copy it to another one? - for simulation you can modify the process image as required. PW/SFC14/15 will need simulation DB's


:whistle:
Is that data area accessible by ALL external I/O drivers.?
Another benefit of mapping is that the state can be invested easily, same as if a point has to be changed due to failure (as Bit Doc said)

Some peeps even have input AOI/FB/Function etc that have inbuilt Debounce On/Off & one shots..
 
Re the async/IO refresh/read methods, they are different.

The logix platform implemented the asynchronous method as standard at its inception with the Producer/Consumer Model.

The IO read during a scan has been in all PLC’s for a long while & whilst acts as asynchronous I do not think it is actually classed as an asynchronous update..? (Could we’ll be wrong here though..)
 
Another benefit of mapping is that the state can be invested easily, same as if a point has to be changed due to failure (as Bit Doc said)


For siemens, code put at the start of OB1

Invert:


Code:
AN I0.0
= I0.0
Failed input
Code:
A I0.1 //spare good
= I0.0 //used failed
 
For siemens, code put at the start of OB1

Invert:


Code:
AN I0.0
= I0.0
Failed input
Code:
A I0.1 //spare good
= I0.0 //used failed

OB1 is cyclic right?
so if an input is refreshed using mid-scan what will the result be?

Code:
A I0.1 //spare good
= I0.0 //used failed
So this is 'technically' mapping..


Is that data area accessible by ALL external I/O drivers.?
I'm assuming the process image is the I/Q area, which to best of my knowledge most IO drivers support.
At the end of the day, it comes down to preference/style/standards etc, which is what the OP was asking..
 
OB1 is cyclic right?
so if an input is refreshed using mid-scan what will the result be?

Siemens processors update I/O synchronously. The input Process Image is updated with a copy of the physical inputs prior to executing OB1 and the output Process Image is used to update physical outputs at the end of OB1.

When you address I 0.0 that is the Process Image and not the actual input and beciuse it's a memory location you can write to an input to change its state until such time as it gets overwritten again.

In a similar manner, you can write to the same output in your program many times during one cycle and, because you are writing to the process image and not the actual output, the output actual state only updates at the end of OB1 (unless you write to the Peripheral Output PQWXXX). So, only the last piece of code executed during a scan actually affects the physical output.

So for Siemens processors it doesn't seem to make any sense to make a memory copy of a memory copy and Ive often written simulation code that manipulates the process image.

I hear that Rockwell CPU's can update I/O asynchronously and that sounds odd to me and would be likely to catch people out.

Nick
 
Last edited:
No one mentioned it, but if you are to make a program that needs offline testing you can have a function that maps all your inputs to the hardware and a function that runs your plant simulation and choose between which to use. This allows you to link up simulation in an easier way to your control logic than IO. Although Siemens does have nice simulation tools which would negate this need.
 

Similar Topics

Hi everyone, I am normally not in Siemens PLCs, so I have a relatively beginner question. In a data block (DB3), I added a few rows to it. When...
Replies
8
Views
1,959
Hello everyone, As you can see in the screenshot below i have some values that are retentive. Now i want to create a specific value for specific...
Replies
5
Views
1,490
For an automation project we need to program for the first time in TwinCAT (V2). The Twincat software and PLC control is new to me. Programming in...
Replies
7
Views
5,104
Hello all, I am trying to read DB values from an S7-300 with CPU 317-2 DP. I have done this before with a CPU 313C but it had a CP 343-1 Lean...
Replies
14
Views
4,799
I have a function block (FB1) which uses internal tags and has made a data block (DB1). I have a created a PLC data type with around 15 tags and...
Replies
2
Views
1,686
Back
Top Bottom