Ignition SCADA recipes

Hello,

We plan to use ignition Scada for the first time, in a project that has recipes.
I saw a video where it is demonstrated, but still I would like to ask your opinions.
How is it compared to the WinCC flexible recipe engine? How do you add records to the database and so on?
Would you say it is easy to implement?

https://www.youtube.com/watch?v=jKobEciHbm4&list=PL652395FCD92073F4&index=28

Regards

I can't compare it to WinCC's recipe engine as I've never used it.

Ignition has a recipe module which is not what is being demonstrated in that video. In the video they are using the transaction manager instead. The module offers a suite of recipe management tools. I looked at the recipe module and found it didn't meet our needs because a recipe has 190 elements in it and we needed to present it in a tabular format that was different from how the recipe manager displayed it. You can find a YouTube presentation on the recipe manager here.

Fortunately, Ignition offers a number of ways that you can handle recipes besides the recipe manager. I used a Python script to query the DB for a recipe and then a system.tag.writeAll() function to load the recipe to the PLC.

It was significantly simpler than handling recipes in RSView32 or FTView.

On the recipe screen I have a save button with applied security. If the user has permission then then save button checks the DB to see if the recipe exits, if it does it updates the record. If it doesn't it creates a new record in the DB.

I also have an offline recipe editor, which doesn't need any scripting. Since it is not writing to a PLC or to any tags, iti s just a screen of data entry fields for editing. It only uses sql query bindings. A logged in user with permission can select a recipe from a drop down and the fields are immediately loaded. When they change a value and confirm it, the DB is automatically updated.

I'll add to this, since I too am using Ignition and using some pretty complex recipes (~800 parameters across ~10 processes).

I had hoped to use the Recipe Module as TConnolly has mentioned, however it is considered an "MES" module and falls under the "MES" licensing structure. This eliminated the use of the recipe module for us as the number of "MES Tracking Points" that I would have required would have make Ignition extremely expensive. My evaluation is that the Recipe Module cost can only be justified if you are providing other "MES" functionality (at least for complex recipes). I will say the Recipe Module was really easy to use when I built my "proof-of-concept" system.

The alternate method was to "roll-my-own" which is extremely easy in Ignition; I had hope to find a solid "of-the-shelf" product, that's a side conversation.

I use python scripting to "save/create/edit" my recipe, it's pretty simple scripting actually. My recipe editor is a table object, pointing to a "Recipe_Edit" table. Users directly edit the data in this table from the table object in Ignition. When saved, the data in the "Recipe_Edit" table is transferred into the "Recipe_Storage" table. This is the table where the run-time data is pulled when needed. The hard part of the design was creating proper tables in my database.

You must consider how you identify your recipes, part of my scripting is creating Universally Unique Identifiers (UUID), I don't rely on unique recipe names.

I differ from TConnolly on the transfer of data to the PLC. I am using transaction groups (TG) to download my recipe data. TGs provide better flexibly, are extremely quick, and I get handshakes to boot! When the PLC requires recipe data it triggers the TG, the TG queries the "Recipe_Storage" database and sends the data to the PLC.

TConnolly, I'm curious as to why you didn't use Transaction Groups?

This is my first project with Ignition as well, and it's by far the best/easiest SCADA package I have used and I'm producing the best "SCADA" project I've ever created due to the power of Ignition. I'm 100% sold on the platform ( but I still need a true recipe and batch solution, so they can do almost everything I need).

You talk about Python and the problem is I have never used it. As I am a WinCC user all my effort was concentraded to learn Visual basic.
I tottally understand the TG method, but I can't imagine how the copy is made from recipe_edit to recipe_storage tables you mention. Could you please explain that part in more detail?

Regards.

Paully's5.0,

I didn't use a transaction group because recipe selection information comes from a barcode. There is some validation that occurs first and some checking to make sure the recipe is a safe one. Then the software makes a decision on which of 25 lines to send the recipe to. At that point it was only a couple of extra lines to go ahead and do it in script rather than build transaction groups.

grnick50

Python is easy to learn, and if you know VB you can pick it up. IMO Python is easier to work with than VB but more powerful. The big difference that you have to get used to is that Python is case sensitive, and it is strict about it. If you have used case sensitive languages before that's not a big deal, but if you are coming from VB it can trip up your code till you get used to it.

Recipes can be edited at the machine once they are loaded. To save changes Python has a query execution command (system.db.runPrepQuery). I pass it a query statment, a tag list, and a value list, and it either updates an existing record or inserts a new record. You need to first query to see if the recipe already exists, if it does then you do an SQL update. It if doesn't exist then you do an SQL insert.

Transaction groups are better than scripting. It just wasn't the best fit for this particular project.

grnick50 said:

You talk about Python and the problem is I have never used it. As I am a WinCC user all my effort was concentraded to learn Visual basic.
I tottally understand the TG method, but I can't imagine how the copy is made from recipe_edit to recipe_storage tables you mention. Could you please explain that part in more detail?

Regards.

Click to expand...

Python is pretty straight forward, the difficult part is learning the methods/calls built into Ignition.

As for transferring data from one table to another, I let SQL do the work. In my python script I build a SQL query to do the work, and python then triggers that SQL query to run on the database. So I leverage SQL queries and functions to handle complex SQL tasks. Python simply builds my SQL statements and commands them to execute.

Inductive Automation has launched "Inductive University" it is a series of videos that walk you through all aspects of Ignition. It's quite impressive and you can learn quite a bit quickly.

Hello,

I am developing the project now and I successfully built a transaction group linked to a DB table that send the recipe to my PLC.
What I want to do now is make a table control in a window so that the user can edit the recipes. I did that table control and I used the table customizer to make the columns editable. However as I read in the manual, to update the table an UPDATE query needs to be done. There is an example in the manual and it talks about an event called cellEdited.
In my version of Ignition (7.7.1 b2014092209), there is no such event, but there is an extension function called onCellEdidted.
Can you please guide me on what code needs to be inserted here to update my table?

Regards

I'm doing the same thing on 7.7.1

See pic.

For some unexplained reason I used the powertable (if i remember well) and not the table component. I changed to the table component and I found the event you used.