So pass all input from PLC_TAG to FC_Input. In this FC make N_, P_, NOT etc. And next make UDT TANK with START, but in FB_TANK use a FC_Input.%I0.0_N_Trig.

I think an FB is better suited to do what you want. 

There are many approaches to building FBs and UDTs.

I tend to go along the following process:

Build an OB (since in S7-1200/1500 we can have _many_ cyclic OBs).

In that OB, I start with controlling just 1 of the things I might have many of (4 in your Tank example).

I get the logic working flawlessly with 1 thing using global tags (for I/O) and DB tags for everything else.

Once it is working, I then put all the logic for 1 of the things into an FB - including all the global tags and IO tags.

Then I slowly replace one global tag as a time an FB interface parameter.

When it is finished, I potentially have a single huge FB interface filled with parameters.

If a see opportunity for a group of UDTs, like input parameters, output parameters, InOut Parameters, I will group them, build the UDTs, and start swapping out parameters - so long as it does not make it harder.

I say the last part because sometimes UDTs make it more difficult to pass parameters in a smooth natural way that is easy to understand, repeat, explain, maintain, and expand.

The UDT for me is the last thing I do rather than the first thing.

For me, the first thing is to get it working.  Then replicate it.  Then see if something will help simplify it - like UDTs, or other data structure(s), or other I.T. type structures / architectures.

bercow

I will not continue a separate topic. Then I have such a situation, TANK x4, perfect for UDT. But.. I will also definitely need N_TRIG for each stop, I will need BLINK 1Hz for each lamp.

If I make UDT TANK, then I will use the same functions for buttons or lamps in FB, but also in other places in the code. I will duplicate the same.

If I insert all I/O into FB and perform operations on them that return useful options (--NOT--, P_ N_, timer etc.) then I will not insert them in UDT, but UDT will be very unreadable.

It seems to me..., that for me (but I don't quite know how) would be to create a function that duplicates what is often used in the code. So pass all input from PLC_TAG to FC_Input. In this FC make N_, P_, NOT etc. And next make UDT TANK with START, but in FB_TANK use a FC_Input.%I0.0_N_Trig.

Or maybe I'm thinking too much :D But I would like to create a general template that will speed up the process of creating new simple project designs.\

------------------------------------------------------------------------------------------
Split from Best Practices for Using UDTs with Physical I/O in TIA .

FC is used when there is no memory requirement for anything within the logic.  For simple input and output without caring about the state of the affected device, then FCs work well.

For VFDs, especially the larger ones (with multiple components which are brought up in stages), enabling the VFD takes a lot more steps, so keeping track of what happened previously and waiting for it to complete lends itself to an FB where the PLC can keep track of the VFDs state, one of which is "enabling line feed in progress", which you cannot tell by strictly looking at I/O for that VFD.

Also, there are some instructions _and_ datatypes which only work in FBs.  Refer to the F1-Help for those as they may vary from PLC to PLC, firmware revs, and TIA Portal versions.

I shared how I do things which are based on experience as well as the typical tasks in my current role - using SIemens PLCs.  In previous jobs, I might have arranged things differently - especially depending on a given chosen PLC manufacturer where certain practices naturally aligned in different orders.

Hopefully you can get better understanding by reviewing my suggestions _after_ you have completed your first job.

And, yes, in PLCs as well as in computers, the DRY principle is very useful - (Don't repeat yourself).

If you find yourself scaling things a certain way 2+ times, it might make sense to create your own FC for each style of scaling.  However, I do not recommend thinking like that until you get it working, or if you find yourself about to create the same tedious and error-prone logic 8-16-32 times.  Then, you definitely abstract the logic into an FB or FC to save you time on those repetitious tasks.

bercow

Thx, for answer :)

So if I understand correctly it should look like this...

I also looked through all the Siemens books on good practices, sample projects. But many of them focus on one topic, omitting everything else, there is not a single complete project. If there is a PLC+HMI, then for example there are no I/O, there are UDT, there are HMI tags, but the data is supposed to appear in a magical way...

-----

Then... that's is correctly step by step ?

1. I create a data type "Tank" .

2. I enter everything I want to have there, all I/O.

3. Now I should create a DB for udt.

4. In this DB I create TankX for each tank.

5. I create FC to rewrite all signals.

6. I rewrite physical I/O to the appropriate udt from DB.

7. I create some FB in which there is all the logic for Tank, as InOut I give UDT.Tank

8. I create FC where I put as many FB as I have Tank, and for each I give "DBudtTank".Tank1, "DBudtTank".Tank2.....

----

Should I create a separate FC and FB for each udt?