recipe database concept for multiple automated systems

Hello all.
I am interested in developing a method to eliminate user data entry at the manufacturing facility where I work. We are a small batch manufacturing facility with dozens and dozens of independent automated manufacturing systems.

Ideally I would like each machine to be connected to a single database. As each batch job goes from one machine to the other, the required data for that particular machine is pulled from a database to run that job based on the batch's part number.
I don't need to go the route of SCADA since all of these machines are independent.
I also don't want to go down the route of having a PC at each system. (I cannot manage the PC's in the facility)

As a proof of concept I bought a couple of Redlion graphite dual-ethernet hmi's which have the ability to save .csv's to an ftp server. I created a standard csv template which could be read by both hmi's. This kind of worked, but the reliability of the file transfer and time taken to read/write a file was a big issue.

Since I have several types of PLC's (AllenBradley, Bosch IndraDrive, GE etc) I would like to connect to this database, there has to be some standardized hardware component to this project. I was thinking a standard HMI with a database capability? This would of course require programming new HMI's for each system but it's certainly an option.

Recently I looked into EXOR HMI's which offer the SQL4Automation connector. Anyone have experience with this?

I am open to any other thoughts or new ideas.

Appreciate the input, cheers

You say that you don't need a scada system, but SCADA can be a great way to share data between the machines. You need to have the central PC for the SQL server anyway, and, as you said, you would probably need to reprogram each machine's HMI anyway. You could probably create a system to share recipes across multiple individual HMIs, but often its cheaper to just buy an already working solution instead of trying to build your own from scratch. I agree, you don't NEED scada, but that doesn't make it a bad idea.

To me, adding a "SCADA" system is the way to go.

Issues:
1 - You have to connect a variety of equipment to get recipe data.
2 - You need an SQL database located somewhere
3 - You need a mechanism to query the SQL data for the proper recipe, per specific machine, specific part number at a specific moment in time.
4 - You need a mechanism to send that queried data to the machine PLC.
5 - You need a mechanism to manage those recipes.

Personally I could throw Ignition and Kepware at this and have a solution working w/o hassle.

1 - Kepware gives you the variety communications drivers you need to tie things together.
2 - Igntion is built for databases, choose MS SQL Server, MySQL...other
3 - You'll have to add logic to your controllers to trigger when recipe data is required, as well as data to filter the query (MachineID, RecipeID, Partnumber...etc). You may also have to add additional logic for storing the recipe once downloaded, and possibly re-triggering if a failure occurs for some reason.
4 - Transaction groups in Ignition ensure accurate and fast data retrial and transfer to a PLC.
5 - You can build a simple recipe editor using Ignition's vision module. This only has to be accessible to the person that is managing the recipes.

Article database

I did a project like this for a customer who had many hundred product variants produced on a set of machines that was fully automatically, semi automatically or manually set up or reconfigured for each product. Much of it was pure labelling data. There should be a limited number of label variants or templates with dynamic data fields.

There are a number of vendors for this kind of labelling software. But I wanted a recipe database system that could also talk to the PLCs to readjust machines, based on selected product or article number. I ended up with system based mostly on standard software

• Database.
• Labelling software
• HMI
• OPC-servers

I started developing the database solution with MS-Access, since it was already in my Office package and I could then immediately start learning SQL language and setting up tables and query tables. But I really dissuade the use of the file-based MS-Access for a live system. Use a real database like MS-SQL or others like Paully's5.0 suggests!

Some working stations or packaging lines didn't have a PLC. In addition to the standard software above, I hired a .NET programmer to make a simple C#-application for printer interface. The print-dialogue that came with the labelling software was not suitable. For example I wanted the system to automatically select the correct label template based upon article number input. You can of course use HMI-software to develop this, but then you have to consider licensing cost.

The marketing department together with the technical product development guys had most of the product data on their hands. But it was not always consistent. Some product details were for example described in words. To make it useful for a PLC, it has to be quantified and standardized. One example: One product parameter could be length. The length is also to be printed on a label. As the products are sold in both US and Europe, the length was printed out either in feet or meters. The PLC or machine measuring system (encoders) counts in pulses. I had a hard time explaining some marketing guys why it was a bad idea to mix up measurement units in the tables that I received.

I have to warn you though; it’s a long walk!