TIA Portal Indirect Addressing/Recipe Management

[ASF]

Hi all,

I have been asked to implement a simple recipe function on a system running an S7-1200 on TIA Portal.

In Allen-Bradley land, my method would be:
1. Create a UDT with elements for all recipe parameters
2. Create an array of this UDT called Recipe_Database with enough array members to store all my recipes
3. Create a single instance of this UDT called Current_Recipe
4. Use a list selector on the HMI to select a value from 0...n, where the selected value represents the desired Recipe_Database array element (so, if I want to load Recipe_Database[3], the user would use the list selector to select the recipe description that returns a value of 3)
5. Use indirect addressing to copy Recipe_Database[Selected_Recipe] to Current_Recipe
6. Drink beer and celebrate

In Siemens-land, though, there a few things I'm not sure of.

1. What would be the best way to structure my data? Should I create a user-defined data type (Struct, I think???) with all my recipe parameters, then create a DB with as many of these Struct's as required? Or can I create a "template" DB that contains my recipe structure, and then create as many instance DB's referencing that template DB as I need to store all my recipes, plus one for my current recipe? Or something else?

2. Is indirect addressing possible in a Siemens PLC, and does it work the same way? Are there any tricks I need to be aware of with indirect addressing in TIA portal?

Any tips and ideas greatly appreciated - I'm stil learning to think like a German

[tarik1978]

Have a look at these links
https://support.industry.siemens.com...dti=0&lc=en-WW

https://support.industry.siemens.com...dti=0&lc=en-CN

[ASF]

I hadn't thought of using the HMI recipe management option. Can anyone comment on it's usability? The PanelView Plus recipe management solution is pretty ordinary and I've always steered well clear.

My HMI here is a KTP600 Basic (full part number 6AV6647-0AD11-3AX0) - does anyone know if this particular HMI has any recipe management functions?

[Rob...]

I've built recipe systems using the same method you describe in the OP.

I've tried the HMI recipe manager, it's ok. A little basic.

Indirect addressing works in Siemens. One thing I haven't tried is multi point indexing like I have in Rockwell. E.g Example_Tag[X,Y]

[sigmadelta]

I have used the HMI recipe management. It stores all recipes on the HMI itself. I've found it very straight forward to use. You can even upload values from the PLC and store in a new recipe data record if, for example, the values were entered in several I/O fields.

The severe drawback in the Basic panels is that you cannot store the recipes onto a memory card or USB stick. The only way to do a backup of recipes is to manually use the backup/restore method in ProSave or WinCC.

KTP600 Basic Recipe management:
● Number of recipes: 5
● Data records per recipe: 20
● Entries per data record: 20
● Size of internal recipe memory: 40 kbyte
● Recipe memory expandable: No

[CommissioningMan]

I have made almost exactly what you describe in TIA14 for S7-1500 with Comfort panels. Depending on your controller and number of recipes, you can store your recipes directly in the retain memory. My system had 1000 recipes with arrays of a hundred LREALS and Strings, so retain memory was right out. I had to use the memorycard with an Array Datablock (DBL) stored on it, and then use read/write functions to load the wanted recipe with indirect addressing. Slow as hell.

You create a PLC Data Type (UDT) and then an array of that datatype. You can use the same DB for e.g. "StoredRecipes" (Data type: Array[0..100] OF typeRecipe) and a single "ActualRecipe" (Data type: typeRecipe)
If you need to edit your recipes, you just edit the PLC Datatype "typeRecipe" and all references are updated.

I'm sure the HMI recipe manager is great if you are mixing juice or paint. But who does that?

[travispedley]

I use the recipe functions in Comfort/WinCC when possible for simple setups.
I've only done one complicated recipe setup in a 1200 and it sucked.
I had to store the recipes in the load memory and load/store them there.
READ_DBL & WRIT_DBL were the functions I had to use to do it.
Inside the DB you set up for storage, go to properties and you have to CHECK the Only store in load memory box.
This will allow you to use a much larger DB than you can fit in the Work memory.

[Lare]

On plc you can have multiple DB-blocks with same variables on same order. (only DB name and number changes)
I think that with SFC20 you can copy full DB from one to another.
So if you make indirectly copy syntax to SFC20, it should be possible to copy variables between DB blocks.
On HMI then is only needed recipe number field and execute buttons.

[spaderkung]

I use the TP700 recipe handling stored on sd card and a S7 1200. What complicates my system little over the limit is that we don't edit recipes (only) in the view but instead have parameter screens throughout the hmi. We also have some access level depending parameters...

So TP700 recipes works well for what's intended, but keeping it all in plc gives more control. And makes it easier to change hmi.

A notification of when a recipe parameter change is pending is tricky either way.

[ASF]

Thanks for all the tips. It looks like the HMI recipe option is out, because I'll need more than 5 recipes. But it sounds like the UDT and indirect addressing method is possible, so I guess I'll head down that path.

Can anyone help me out with a screenshot or article showing indirect addressing in TIA Portal? Most of the examples I've found online are in STL, and I'm kind of stuck with ladder by customer requirement.

[tarik1978]

This thread should help you
http://www.plctalk.net/qanda/showthread.php?t=104280
See also this link
https://support.industry.siemens.com...=0&pageSize=10

[mk42]

ASF,

You can pretty much follow the same steps as you laid out for AB-land, except that the Data type instance will probably be in a DB. In Portal (for recentish 1200s and 1500s), Indirect addressing is as easy as #Arrayname[#indextag], for Ladder, FBD, and SCL. For multiple dimensions, it would be [#index1,#index2,etc].

Two things to watch out for:

1) When you go to add the index inside the brackets, the only thing the dropdown will give you is the different defined indexes in the array (0-100, etc). It will NOT help you browse all the tags, like usual. I generally have to type out the desired tag somewhere else, validate it, and then copy/paste it in.

2) There are a few posts above with different solutions, but you'll need to make sure you consider retentivity. In the logix world, all tags are retentive. If you're thinking like a german, then you only want some memory to be retained, and the rest to be set back to a defined initial value after power up or a download that changes a DB.

A) the simplest solution is to mark your recipes as retentive, but if there is much size to your recipe system, then it probably won't fit.

B) Another option is to write the recipes to load memory via the Read/write_DBL instructions. This sets the start values of the DBs to the current values. However, if you need to change the DB later, the values may not get uploaded into your project.

C) A third option is to use some included instructions to write the recipes to the memory card as a CSV file, with the recipe instructions. This makes it easy to import recipes as well, and the CSV files are accessible over the web interface.

Regardless how you do it, be careful if you make any changes to the recipe data structure after you've filled in the records. It can be very easy for the live data to vanish in a puff of logic.

[Lare]

2. If you write values to DB-block, they are all retentive by default, but download of DB will set them back to init values.
(with siemens you need offline -> online copy, and you have backup of parameters also on offline project)

This is case if you haven't selected optimatez block access.
With optimatez access you can select if seperate symbols are retentive or not.


Merker words (MW, MD, MF) are only retentive, if you config them from hardware to retentives.

[JOLTRON]

Originally Posted by Lare

2. If you write values to DB-block, they are all retentive by default, but download of DB will set them back to init values.
(with siemens you need offline -> online copy, and you have backup of parameters also on offline project)

This is case if you haven't selected optimatez block access.
With optimatez access you can select if seperate symbols are retentive or not.


Merker words (MW, MD, MF) are only retentive, if you config them from hardware to retentives.

I believe in the 300's all DB's are retained by default, but I thought this changed in the 1200's and 1500's. I believe you have to check a box in the DB to specify what data you want retained.

Not sure how the M area works in the newer processors either. In the 300's I remember the HW config had an area where a default 16 bytes or so were defined as retentive.

[ASF]

Originally Posted by mk42

ASF,

You can pretty much follow the same steps as you laid out for AB-land, except that the Data type instance will probably be in a DB. In Portal (for recentish 1200s and 1500s), Indirect addressing is as easy as #Arrayname[#indextag], for Ladder, FBD, and SCL. For multiple dimensions, it would be [#index1,#index2,etc].

Two things to watch out for:

1) When you go to add the index inside the brackets, the only thing the dropdown will give you is the different defined indexes in the array (0-100, etc). It will NOT help you browse all the tags, like usual. I generally have to type out the desired tag somewhere else, validate it, and then copy/paste it in.

The same applies in AB-land, so no problems there.

Originally Posted by mk42

2) There are a few posts above with different solutions, but you'll need to make sure you consider retentivity. In the logix world, all tags are retentive. If you're thinking like a german, then you only want some memory to be retained, and the rest to be set back to a defined initial value after power up or a download that changes a DB.

Ah, yes, the old non-retentive memory trick. I will be sure to watch out for this one.

Originally Posted by mk42

A) the simplest solution is to mark your recipes as retentive, but if there is much size to your recipe system, then it probably won't fit.

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

Originally Posted by mk42

B) Another option is to write the recipes to load memory via the Read/write_DBL instructions. This sets the start values of the DBs to the current values. However, if you need to change the DB later, the values may not get uploaded into your project.

C) A third option is to use some included instructions to write the recipes to the memory card as a CSV file, with the recipe instructions. This makes it easy to import recipes as well, and the CSV files are accessible over the web interface.

Regardless how you do it, be careful if you make any changes to the recipe data structure after you've filled in the records. It can be very easy for the live data to vanish in a puff of logic.

I'll keep those options in mind. It's been a while since I looked into TIA but I vaguely remember configuring some DB's to be retentive, so I'm sure it's doable. The system as it currently exists stores what will ultimately become the recipe settings in a DB, so obviously they're retentive - they don't have to re-enter all the parameters when they power cycle the machine. It's just a matter of me giving them multiple copies of those existing, already retentive settings.


Thanks a heap for the very thorough advice!