Need Advice - Packaging /Converting DB

[Geoffy1]

Hi All,

I am looking for some schema advice on how to go about developing a process monitoring tally for a converting line.

Basically,

I have a printing press which prints a web of material. I currently track data points such as heat temperatures, ink pH, paper roll traceability, and so on, which is done on paper throughout the production run for each roll of stock.

The Settings recipe is setup previously which gives the operator targets but then the operator records the actual points on a sheet every roll.

What I can't figure out is:

1. How to relate a recipe with an operator entry sheet and then apply those entries to each roll?

If anyone has any ideas or even a similar solution let me know. I need to get over this hump and I think I'm making it harder than it looks.

Thanks

Geoff

[eos]

If I understand correctly, Recipe and Recordings (R & R) are basically the same thing, except one has the target values, the other are the actual values.

If so, then create one child table which holds both. Create a recipe upfront with the target values, then let the operator add and fill in one recording per roll. On your Process layout, display them in a portal sorted by creation timestamp, so the recipe is at the beginning, with all the recordings following. (Don't forget to create the creation timestamp field; every home table should have one … and a modification TS, too)

You also should flag the Recipe records (or both types); this way you have a method to suppress Recipes in reports or summaries (if so desired), and also are not dependent on the creation order to display R & R in their proper order. (And you can do conditional formatting, display an overview of Recipes only etc.)

[comment]

1. How to relate a recipe with an operator entry sheet and then apply those entries to each roll?

It would help knowing what do you intend to do with this data after it's collected. For example, for computing the averages of selected parameters, it would be more convenient to record each data point as an individual record (recording the parameter and the actual value).

In any case, your operator obviously needs to choose a recipe before they start. It's not clear to me if this choice applies to the current roll only or to multiple rolls in a batch, though.

---

See also:

http://fmforums.com/forum/topic/79864-prevent-changes-from-affecting-previous-records/#entry371737

Edited August 20, 2012 by comment

[Geoffy1]

It would help knowing what do you intend to do with this data after it's collected. For example, for computing the averages of selected parameters, it would be more convenient to record each data point as an individual record (recording the parameter and the actual value).

In any case, your operator obviously needs to choose a recipe before they start. It's not clear to me if this choice applies to the current roll only or to multiple rolls in a batch, though.

The "initial target parameters" are entered by an engineer before the job starts. The "Actual" monitoring values are entered by an operator every 15 minutes or so/or the length of the roll as it runs off the printing press. The Initial Target Parameters would be like a baseline that the operator needs to adhere to within a range such as a high and lower limit.

The roll is tracked like a tally sheet but I want to keep the "actual" monitoring values entered with the roll or record, when a new roll or record is started the initial target parameters are still visible. I know I would have to have two separate tables for Targets and then Actual but how would I join those to the Roll Record? It seems like it would be easy but I am clueless.

Real time process monitoring is the ultimate solution but I wanted to use this database more as a record tally and have the ability to store process information with each roll.

[comment]

Do all jobs have exactly the same parameters, just different target values?

Also, you haven't answered my question regarding the intended use of the data. That is, I am still not clear if it's worth to separate the actual values into individual records. That can make quite a difference.

Edited August 20, 2012 by comment

[Geoffy1]

Each job would have the same parameters but the target values will differ. If a certain parameter is not used then I am adding a "N/A" value as a default for each record on the target side of the table.

The data itself is more for traceability if quality issues arise.

For instance, if a tension issue happened in Record/Roll # 13 we can go back and get the "Actual" entered values that were recorded during the end of that Record.

We would be able to see that the operator recorded an acutal value of 10 during the run of roll #13.

[comment]

Perhaps this could serve as a starting point?

ParameterLog.fp7.zip

[Geoffy1]

It is a start, thank you for your help!

Rock on!