TIA Portal Indirect Addressing/Recipe Management

One other question: how can I copy a UDT to another UDT in TIA? In AB land, it's as simple as a COP instruction, and right or wrong, it'll copy the exact number of bytes you tell it to wherever you tell it.

I don't suspect the Germans are are carefree with their data manipulation. I thought MOVE_BLK might do it, but apparently not.

If I have to do it by brute force, it's not a huge drama as there are only a handful of parameters to each recipe. So if it's a matter of writing an FC to manually copy each recipe parameter, so be it - but if there's a better way, I'd like to learn about it in case I have to do this on a recipe with 100 parameters next time

ASF said:

One other question: how can I copy a UDT to another UDT in TIA? In AB land, it's as simple as a COP instruction, and right or wrong, it'll copy the exact number of bytes you tell it to wherever you tell it.

I don't suspect the Germans are are carefree with their data manipulation. I thought MOVE_BLK might do it, but apparently not.

If I have to do it by brute force, it's not a huge drama as there are only a handful of parameters to each recipe. So if it's a matter of writing an FC to manually copy each recipe parameter, so be it - but if there's a better way, I'd like to learn about it in case I have to do this on a recipe with 100 parameters next time

Click to expand...

One of the awesome parts about doing optimized, symbolic programming in TIA is that as far as it is concerned, a tag is a tag and a data type is a data type, regardless whether it is elementary (bool, int, etc) or complex (struct, array, udt). Just use a MOV. Portal knows how long it is, and moves the right amount. For example, you can use MOV to transfer DB.recipe[5] into #activerecipe, as long as they are the same UDT.

Now if you need to move indexes 12-23 to 44-55, then that's a little bit trickier.

ASF said:

My recipes only have about 8-10 parameters (one string and the rest integers), and there are only 10 recipes. So memory space is probably not an issue

Click to expand...

One thing about terminology, while discussing "thinking like a German": in the Siemens world, they're are 3 layers on a recipe system: Recipes, data records, and elements. I often see people thinking about it with only two levels, so I wanted to clarify before you get lost in a help doc somewhere.

Recipes are like new tabs in a spreadsheet, data records are like the rows, and elements are like the columns. Each recipe defines the elements/parameters, and links them to different tags. Then you add new data records to populate different values for each element.

If all you need is array[1..10] of one UDT, then that would probably for in a basic panel OK. If you have 10 UDTs, then the basic panels can't handle it.

mk42 said:

One of the awesome parts about doing optimized, symbolic programming in TIA is that as far as it is concerned, a tag is a tag and a data type is a data type, regardless whether it is elementary (bool, int, etc) or complex (struct, array, udt). Just use a MOV. Portal knows how long it is, and moves the right amount. For example, you can use MOV to transfer DB.recipe[5] into #activerecipe, as long as they are the same UDT.

Now if you need to move indexes 12-23 to 44-55, then that's a little bit trickier.

Click to expand...

For the first time perhaps ever on a Siemens system, the answer was simpler than I thought

In AB world, of course, mov ("MOV") only works on numbers, and has inherent datatype conversion. Where you just need to copy data structures, you use copy ("COP") which literally just copies data from one place to another without care for what it means or does. So I never thought to try the MOVE instruction in Siemens!

Thanks!

with 8-10 parameters and only 10 recipies, it won't make big diffrence if you use brute copy /move for every bit and word.

I would probably do this with like on old 300. Make FC block with 10 inputs and outputs. Inside FC move inputs directly to outputs.

On another DC call this 10 in/out FC with enable pin.
On enable pin use and-block with recipe number and transfer bit.

So you have then 10 networks which copy from 10 (recipes) DB's to valid DB.
And 10 different networks for copying valid parameters to recipes.
Simple to understand also for others

If there would be more data, then UDT or copying DB block directly to different areas would be better approach.

For winCC there was also Siemens example how to copy variables from PLC to excel file. Same example was also for some panels.

https://support.industry.siemens.com/cs/document/106501825/how-do-you-store-data-with-a-script-in-a-file-with-wincc-%28tia-portal%29-pc-runtime-?dti=0&lc=en-WW