DB Sizes

I have an S7 application that involves a fairly complicated recipe for process control. My original idea was to create a UDT for the basic structure of a single recipe then create a DB with an array variable of type UDTx.

The problem is that the basic structure for a single recipe is right at the size limit for the DB and even an array of 2 elements exceeds the size limitation.

Now I'm not stuck on having all the data in a single DB but I need a way to Address the DB indirectly if I'm to used a separate DB for each recipe. I'm guessing that building a string with the DB Name and setting a pointer to it won't work.

If anyone has some example code of how to indirectly address a DB I would appreciate it. I have indirect addressing working inside the DB (Thanks to you guys). I will have around 25 recipes to start with but with the option of adding more later. So I need something that will let me stipulate;

DB1.Variable or
DB2.Variable ... DB25.Variable

Alternately if anyone knows of a good work around for the size limit, I'd be really interested in knowing about that as well.

Eric

Just another idea, why not use one DB for the current recipe and then copy in data from the other DB's when an alternative recipe is required.

dbs

L D[AR2 said:

Just another idea, why not use one DB for the current recipe and then copy in data from the other DB's when an alternative recipe is required.

Click to expand...

LD,

That's the intent, to have a DBz as Current Recipe, then have my 25 or so individual DB's for the recipe's, then when I select say recipe 16, I will copy DB16 to DBz. But I don't want to have 25 rungs of logic that say

IF user selects DB1 then copy DB1 to DBz or
IF user selects DB2 then copy DB2 to DBz
and so on.

I want 1 rung that says
Copy DB[user_selected] to DBz

Is there a way to do this?

Eric

Yes. I posted a generalised copy block a while back - I'll search for it.

this one?
http://www.plctalk.net/qanda/showpost.php?p=157624&postcount=7

STL??? said:

this one?
http://www.plctalk.net/qanda/showpost.php?p=157624&postcount=7

Click to expand...

LD. Once again I owe you. Many thanks.

Eric

STL??? said:

this one?
http://www.plctalk.net/qanda/showpost.php?p=157624&postcount=7

Click to expand...

LD,

Well... That function looks like it could be a valuable tool, but it doesn't actually permit me to index through DB's. It will let me index through elements of a named DB.

What I need to be able to do is have a list in my HMI of Recipe1 through Recipe25. In the PLC Recipe1 is a DB1, Recipe2 is DB2 and so on. When the user selects recipe 20 for example I don't want to have to actually have an exclusive branch or rung to deal with that particular selection. In case I'm not effectively conveying what I'm trying to do, here is an example of how I would do this in Logix5000 structured text.

cop(recipe[HMI_recipe_selection],loaded_recipe,1)
Recipe being the Array Tag Name
HMI_recipe_select being an integer value written to by the HMI
and 1 being the number elements from that array to copy

This way as the number of recipes grows over time, the logic or code doesn't have to be modified to accomodate additional elements.

I'm pretty sure I could do this in S7 with the functions you've given me, if I could create a single array of 25+elements derived from my recipe structure. But the size issue. I question that what I need to do can be done, based on what I know about programming in general. In C++ or Basic you can index through elements of arrays but you cannot index through programatically a series of Variables with like names and consecutive numbers appended to the end. You just can't build a string and turn it into a variable pointer. I'm afraid that's what I'm up against here since the DB's aren't truly an array, how does one build a pointer to it? I will have only an integer number of the recipe I want to load and will need to have that number point to a corresponding DB without having to actually name the DB. I suppose alternately I could preemptively create 100 DB's and then hard code the 1=1, 2=2, 3=3.

Eric

You should do the recipe in the HMI. Then all you need is one DB in the PLC.

Charles,

That's about the only option I have left at this point, if the customer will permit it. What is so frustrating about this is this same program is running at another customers site with ControlLogix and I have 2 UDT's, The first UDT defines segments of the recipe, the second defines a Variable Array of Type Segment which comprise a single recipe, then I have a Tag of Type Recipe that is an Array of 100 elements, and it just works so neat and clean.

Then I just copy recipe[x] to my loaded recipe tag and voila'.

I keep hitting walls with S7 and having to go at things from completely different angles, and it has changed my entire program structure, which is a very well tried and tested program. It seems to me that AB is miles ahead of Siemens in flexibility and ease of addressing. I've never hit a memory constraint like this in AB.

Thanks for your help, I'm keeping my fingers crossed that the customer will go for recipe storage in the HMI.

Eric

Your original post said:

Copy DB[user_selected] to DBz

Which is what you can do with the block I've written. Are you trying to do something different now ?

Here's an example of the copy block:

So does the iSourceDBNumber override DB1?

If I stipulate DB1 as dbSourceDB and iSourceDBNumber as 15 then I do I get DB15 or DB16? And can I use an INT Variable for the iSourceDBNumber or do I have to use a constant?

Yes it does override it.

If iSourceDBNumber=0, then the block uses dbSourceDB otherwise it uses the integer value passed in as the source DB number. The same rule applies to the destination parameters.

iSourceDBNumber has to be an integer. A constant or a variable will work.

If you hover your mouse pointer over a parameter name, a hint will appear for each parameter.

Perfect! I will give this a shot tomorrow morning, this is going to be a big help, thanks a million.

Eric