Finding a String to ID an Array number - TIA Portal

[russg]

Hi,

I'm looking for a way to find the correct recipe number from a String ID.

I have an array [amount defined by constant] of recipe UDT.

Each recipe has a String ID.

When I receive a recipe command to load from the MES system I want to find said recipe in the correct array location and then send recipe into loaded DB location.

I want to do this without writing a line for every recipe and doing a string compare because the recipe quantity could change.

I'm assuming this is best done with SCL and for it to index through to find the string and recipe.

Has anyone done this or know how to?

Thanks.

 

[parky]

perhaps post a screenshot of this data not quite understanding exactly what you are trying to do.
For example is the MES sending the recipe string and you need to find the start of the recipe array that contains this string here I'm assuming the first variable is the recipe string ?.
Need to know what is sent, the structure of the recipe etc.

 

[L D[AR2P#0.0]]

Example implementation:

 

[JeremyM]

Yeah, you could do a string search, worry about casing, and so on. How does the MES know the recipe exists? What happens if it isn’t found?

 

[parky]

Again, really need to know more information.
Based on what you have posted, it looks like the recipes are stored in datablocks within the PLC, the MES sends a recipe name, the PLC then looks up the recipe name & loads the recipe i.e. transfers it from a DB to a working DB.
There are many holes in your description, are the recipe names stored just as a list of recipes & some values that point to a DB area for that recipe ?
Are the recipes configured for example:
Recipe_Name
Recipe_Desc
Recipe_Variables......
again this could be all recipes contained in one DB
Or seperate DBs for each recipe
I do not have TIA loaded at the moment but itteration through a loop is one way to go for example let's assume the recipes are in separate DB's
The first variable i.e. DBW 0-8 (a string with recipe name)
The length of each DB is say 400 words & the DB's are DB10 to DB50 (40 recipes).

Then set a pointer to 10
Compare DB[pointer].Recipe_Name
With the MES recipe name if true then move that DB to your current recipe DB
if not increment the pointer, check pointer is less than 50, repeat .
I'm not fluent in S7, was in S5 so perhaps people like Jesper LD etc. could point you in the right direction, but to get valid answers you need to expand on the recipe structure etc. not saying you should expose your recipe as such just some idea i.e. just like above.

 

[russg]

Example implementation:

that looks perfect. Thank you.

Finding the array number is exactly what is needed.

 

[JesperMP]

Why not arrange the recipes how it is done normally, by number ?
A name in the form of a string can be an additional information, but not the main ID.
That you have to jump through hoops to get it to work shows that it is not the right way.

If you absolutely cannot change the recipe system on the MES side, then let the MES do the searching and find the ID by the number. Just make sure that the recipe number does not exist twice in the MES.

edit: In the recipe system by text ID, how do you ensure that the same text ID doesn't exist twice ?

 

[russg]

Why not arrange the recipes how it is done normally, by number ?
A name in the form of a string can be an additional information, but not the main ID.
That you have to jump through hoops to get it to work shows that it is not the right way.

If you absolutely cannot change the recipe system on the MES side, then let the MES do the searching and find the ID by the number. Just make sure that the recipe number does not exist twice in the MES.

edit: In the recipe system by text ID, how do you ensure that the same text ID doesn't exist twice ?

I wish I could, but I'm not designing the MES/SCADA side, just the PLC side.

The MES has already been specified to choose the recipe using a STRING.

One of the pros of using the String is that we don't have to align text lists to be sure it is the correct recipe. One of the cons is that the String has to match exactly or it won't work.

That is a good question about making sure it doesn't exist twice. I will have to add that into the code so it cannot be possible to create a duplicate name. Thank you.

 

[parky]

I'm surprised that the recipes are not sent from an SQL database to the relevant PLC's or at least selected from the PLC's, having to rely on recipe strings in two places is prone to errors, if they have an MES system then would assume they have servers with databases.

 

[russg]

I'm surprised that the recipes are not sent from an SQL database to the relevant PLC's or at least selected from the PLC's, having to rely on recipe strings in two places is prone to errors, if they have an MES system then would assume they have servers with databases.

This maybe how it evolves eventually, but the machine I'm working on isn't a typical process cell. It is machinery automation (lots of motion control/servos). The standard for the machine builder is to have recipes stored on the PLC side.

When I've worked on process projects with full SCADA control the recipe is always stored in the SCADA DB/SQL like you mention. This system has zero SCADA control apart from work order downloads, recipe selection and some process limits.

I agree, it could cause some problems if it isn't thought out properly and designed well.

 

[parky]

Yes, we had a similar problem, had over 20 machines, the PLC's were middle range, however, it could only hold about 10 recipes as the retentive memory was limited, the machine setters had to load an existing recipe & modify it temporarily as usual bubba would get the settings messed up, no idea why but the machine builder used the PLC when the HMI's had recipe ability, I modified it, this gave us many more recipes, I eventually wrote an interface where new or modified recipes that could be configured on the management system & downloaded to the HMI's.

 

[JesperMP]

There are many ways to do recipes.

One way is to copy all recipes from the MES to the machine. In this way the operator can select a recipe, even if the machine is offline. Therefore the recipe exists in 2 places, the MES as well as in the machine(s). It seems this is what you do. Every time a recipe is changed, it has to be sent to the machine(s).

Another way could be that the recipe is handled entirely by the MES system, and every time a new job is to be started, the MES sends the complete recipe contents to the PLC rather than just an ID. Part of the data could be the ID no and/or the ID String which then can be displayed for the operator on the HMI.

What we do is that the operator specifies the recipe no on the HMI. The machine then fetches the recipe content from the database (i.e. the MES), but only to a temporary buffer. Part of the recipe is a textual description of what the recipe is. The operator checks on the HMI if everything looks right, and if OK he then uses a button to copy from the buffer to the next active job.

Yet another version is that the MES also handles what jobs are to be started, and the MES sends the job details to the machine, i.e. the number of parts to produce and the recipe. The operator still have to check and accept if the job looks OK.

 

[parky]

Yes I agree, one system (not done by me), the supplier who did the system assumed the Scada system was accessable from the plant by the operators (as per an existing system), however, the management were not keen on this, the supplier had to do a quick re-think & decided to implement a work around, the scada would reside in the control room (un-attended) appart from maintenance.
Product development produced or updated recipes in an existing IBM based system, this was ported to an SQL DB on a server, then using RDS to upload the the recipe via the Scada to the master PLC, this then copied it to the relevant batching PLC & uploaded to the HMI's own recipe system (the HMI's had no connection to the network). It was a bit of a botch but worked, unfortunately I was not involved with this side so did not know about it until commissioning started, it worked well, if the Scada was not availlable it meant it could be still used, there was some checking of recipes were current that everytime a recipe was selected, the batch PLC would send a message to the scada, that in turn interrogated the Database to verify the recipe eas valid.
When we upgraded the other system I insisted that the scada with two stations be in the production area, the system was upgraded to use the same recipe database as the other, to ensure that if the link between the scada & the SQL server was lost, every time the recipe was selected by the operator it was written to the local scada HD as a csv file, if the SQL server could not be reached, it would load the csv, there were no problems with syncronistation in reallity as every time the recipe was downloaded a copy in csv format would overrite the one on the local HD (note: not a small recipe structure it contained over 2,500 tags). Although the two plants worked in diiferent ways, the recipe originally designed for the newer plant had a recipe based on a 100kg batch (minimum size that could be handled), so the ingredient additions were based on that, when the operator selected a recipe they entered the batch size required, simple maths calculated each ingredient addition required, also extra fields had been added to each recipe stage for the new plant so these could be used for any special requirements for the upgraded plant, each recipe stage contained the information for the type of operation for example a field for the type of operation i.e. oil addition, water addition starch addition & so on, a temperature, if blending required so when a stage was loaded, it would contain all information but only the fields required would be used, even down to the transfer stage so for an ingredient addition only the fields required would be used, the others would be null or zero, the last stage i.e. transfer all fields for other operations would be null & only the transfer parameters used. This way we could have two plants that worked in different ways but use the same recipe.