Possibillities new project, MP277 317-2PN/DP

[userxyz]

Jesper

Yes indeed, that's what he wants. Report is something they want too, indeed. PCS7 is overkill for what they want, I tought wincc flex could do the job without paying extra money...

Many recipes

only 10 varibles / recipe

Max number of batches = 50


Operator needs to start them manually (out of the recipe window) ?

If I understand you correctly, then your customer wants to make a production plan, in other words send a list of batches to different recipes, and the system should then automatically make each batch in turn. I can imagine that they also want a report for each batch.

There is an option for PCS7 called Simatic Batch. I think it will do what your customer needs. But PCS7 is a completely different to WinCC Flexible.

In theory OPC XML should integrate with Microsoft Office, because XML is a Microsoft standard. But I have no experience with it.
Just use OPC DA between the PLC and the office PC.

How many recipes ?
How many variables per recipe ?
How many batches in the queue at one time ?

 

[JesperMP]

To me it sounds the operator is not supposed to change the components in each recipe. He just have to start each batch job that is predefined by the Office PC.
Then dont use the recipe system in WinCC Flexible.
In stead you can program the batch handling in the PLC.

10 variables per batch, and 50 batches makes 2 kB data if they are reals. Your PLC can easily handle this. You can even reserve some space for a name or comment to each batch. 20 characters for example would only add another 1 kB to the list.
This also opens up for that you can view the list of batch jobs on the HMI for example. You can do a lot with multiplex tags so you can see all components of all recipes.

As for the PLC program:
You can make an "in_buffer" where the Office PC states the next batch job, and you can make a "batch_list" with 50 slots.
When the in_buffer is filled with a new batch job, you put the batch job in an empty slot in the batch_list - and you clear the in_buffer.
You can also make this conditional. For example let the operator review the data in the in_buffer before it is accepted into the batch_list.
When the operator selects and activates a batch job, you remove it from the batch_list.
The rest is just programming. I would do it in SCL because you can make an index number for the batch list and in SCL it is dead-easy to plough through the list with a FOR NEXT loop.

 

[userxyz]

Sounds very good

Sounds very good...

The operator does not need to change productparameters, but, with a passport, the current batch it's productparameters should be able to be changed on the MP277.

But your idea sounds very good, I think I will folow you in the way you describe. The plc has to receive the batches with the corresponding productparameters. All in a buffer. And deleted out of the batchlist when the batch is running. I will send everything via OPC.

So Batches will be made in MS ACCESS (will do it in access). Recipes with the productparameters are stored in an access database. When they want to run products of a certain product, then they make a batch with the recipe in it and the number of products they want. This is send to the PLC.

In the PLC (written in SCL) the batches are buffered. A batch-name/number contains the recipe and the number of products they want to run. All stored in DB's.

On the HMI, the operator just needs to do 2 things with the batch. When he wants to run a new batch, then he says, call batch with a button. When the batch is called, the machine needs regulate to the parameters in the batch, therefor a 'reset machine' has to be done that uses the parameters of the choosen batch. After the reset he can start to run the batch.




Do you agree ?

To me it sounds the operator is not supposed to change the components in each recipe. He just have to start each batch job that is predefined by the Office PC.
Then dont use the recipe system in WinCC Flexible.
In stead you can program the batch handling in the PLC.

10 variables per batch, and 50 batches makes 2 kB data if they are reals. Your PLC can easily handle this. You can even reserve some space for a name or comment to each batch. 20 characters for example would only add another 1 kB to the list.
This also opens up for that you can view the list of batch jobs on the HMI for example. You can do a lot with multiplex tags so you can see all components of all recipes.

As for the PLC program:
You can make an "in_buffer" where the Office PC states the next batch job, and you can make a "batch_list" with 50 slots.
When the in_buffer is filled with a new batch job, you put the batch job in an empty slot in the batch_list - and you clear the in_buffer.
You can also make this conditional. For example let the operator review the data in the in_buffer before it is accepted into the batch_list.
When the operator selects and activates a batch job, you remove it from the batch_list.
The rest is just programming. I would do it in SCL because you can make an index number for the batch list and in SCL it is dead-easy to plough through the list with a FOR NEXT loop.

 

[userxyz]

loop

PS:

About the advice to use SCL...

For the buffering thing (fifo in list), a for next loop can indeed be interesting, is this why you mean to use SCL ?

 

[Bratt]

*: You have to investigate it yourself to be sure. I dont use the native recipe system myself.

Here is an alternative worth considering:
I have made my own recipe system, where all the various recipes are stored in the PLC. The main reason for this is that I then do not have to worry about that there must be a live connection to a recipe server.
The various recipe editing locations then become a kind of "dumb clients".
The cost is obviously that it eats memory.
For my purposes I have 99 recipes with 50 REALs. This eats 20 kB PLC memory. Luckily for me, PLC memory isnt such an issue as it used to be.
If you have 1000 recipes with 200 REALs, then it would cost 800 kB ! So it isnt a solution for everybody.

This is usally how i do it aswell. If you have huge recipes you can use unlinked data blocks and SFC 83 "READ_DBL" to save memory and just move the recipe currently in use to a regular datablock. Its not suitable to write frekvently do datablock stored in this manner but i find no restrictions on reading.