How do I store parameters for hundreds of different jobs in AB ControlLogix

I am looking for the best way to store and recall parameters for several hundred different jobs for a machine control. Each job will only have about 10 parameters, half of which are servo index locations, but the machine has several hundred different jobs it runs, and right now the parameters are being stored on index cards in a card box.

I have used a lot of SLC500s with Ultra 3000s in the past, and we stripped a large stash of ControlLogix / Sercos components off of a poorly designed welding robot we bought at auction. We are building a third machine, and I want to use this as an excuse to dive into the ControlLogix stuff. I know that I can use arrays to organize data like this, but I'm thinking that the user is going to have to be able to add in new jobs quite frequently, and I'm not sure if new tags can be added to an array on the fly. I have done an extensive amount of MS-Access programming, so I was trying to find ways to write to the tags that way.

What are some other good options for storing job parameters and recalling a job from an HMI which then loads those parameters into the correct tags to run that job in the machine?

How feasible is using MS-Access and VBA to write to the tags? How would I connect to the PLC?

For our machines I have created a UDT (User Defined Type) with all the variables needed for one job. You may include a string description among those.

Then create an array tag of that type. Make the array as big (or a significant % bigger) than the number of jubs you anticipate.

A Job_Number DINT tag can be used to index to the appropriate entry for a particular job. Have fun.

We call them recipes. For us a recipe has 148 parameters, and there are hundreds of them. The recipes are stored in a database.

In the ControlLogix we define a UDT in order to organize the recipe under a tag named RECIPE. Only one Recipe is in the ControlLogix PLC at a time.

We use a PC based HMI and the HMI runs VB to query the DB, retrieve the parameters, and then write them to HMI tags that are mapped to elements in the ControlLogix RECIPE UDT tag. The operator scans a barcode and the barcode is used to find the right recipe in the DB.

You can use Access to write to the PLC but I'm not sure it is your best choice. You will need an OPC server such as RSLinx Pro or one of the others that is in the market.

I would go with the PLC based array tag of a user-defined structure. Build the structure (UDT) to incorporate all the variable parameters for the "jobs"

A single tag can hold 2 Mbytes of data. 10 parameters of DINT data-type will be 40 bytes, so a single UDT array tag will be able to store thousands of your parameter data blocks

Use the HNI to select the "working" data-set, i.e. it's just a pointer into the UDT array.

There'll be no comms overhead for loading a "recipe" into the controller for production, just an index number is all that is needed.

Thanks for the replies. I understand in concept what you're suggesting, but I'm not sure how to apply it. I made a UDT_Jobs with 5 Members (Bend_1,Bend_2,Delay_1, and Delay_2). Do I need a member for the job number as part of the UDT also, or is the point of the array to have and use a two dimensional array, with one being the job number and the other being the UDT?
I'm assuming then that the user will set a value in the HMI which will then look up the corresponding data stored in the UDT, but what instructions are used to read the job number from the HMI and then transfer the UDT data into, say, a MAM instruction? Job numbers are already established 7 digit numbers, which is what the user will have to select from the HMI, so I'm not sure if that's an added column of data next to an index number, or if the unique job number is sufficient.

If that doesn't make sense, I'm still trying to understand the useful structure of an array and how to manipulate and us it.

What do you know how to do at this point? Do you know how to create an array in Logix? Do you know how to access array elements? How familiar are you with ControlLogix programming?

As TConnolly said, you cab write directly to the plc from an external application if you have all the required software. If you know you want to write directly from an external application I wouldn't create the array. Just make a single UDT tag for your active set-up an leave it at that.

If you don't want to write from an external app then you will need to use an array of the UDT you create. I would include the part number as part of the UDT as it is an integral part of the record and it allows for a nice operator function.

There are a couple of ways to select the UDT from the array depending on the HMI you have. But if everything is part number based and the operator knows what the part number is I would just have them enter the part number and trigger a search through the array for that part number. Once it is found, I would indicate it is found and prompt the operator to load the values. I would also prompt the operator if the part number is not found.

Keith

CevinMoses said:

Thanks for the replies. I understand in concept what you're suggesting, but I'm not sure how to apply it. I made a UDT_Jobs with 5 Members (Bend_1,Bend_2,Delay_1, and Delay_2). Do I need a member for the job number as part of the UDT also, or is the point of the array to have and use a two dimensional array, with one being the job number and the other being the UDT?
I'm assuming then that the user will set a value in the HMI which will then look up the corresponding data stored in the UDT, but what instructions are used to read the job number from the HMI and then transfer the UDT data into, say, a MAM instruction? Job numbers are already established 7 digit numbers, which is what the user will have to select from the HMI, so I'm not sure if that's an added column of data next to an index number, or if the unique job number is sufficient.

If that doesn't make sense, I'm still trying to understand the useful structure of an array and how to manipulate and us it.

Click to expand...

Yes, I would say you need the 7-digit job number as a DINT member of your UDT, because you definitely don't want to be creating an array of size 10,000,000 !!

Make your array of the UDT a size that is reasonable - you said "hundreds" of different "jobs", so say you create an array of your UDT with 500 elements, or jobs.

The PLC will not need to read the job number from the HMI, the HMI will put the number into the PLC, and (with suitable logic) will use that number to trigger code to find the job number in the "job-number" elements of the udt array tags.

Once a match is found, the whole array element (i.e. the job spec) can be copied out into a "working" tag, of the same UDT as the array. Lock it in place while the job is active (inhibit the copy), so that it can't get corrupted while "in use"

Now here's another thought.... most HMI products include some form of "Recipe" management, which basically does all that you need. You may discover that what you want to do is simply a case of configuration of the HMI.. what HMI are you using ?

I used to use SQL Server to store recipe data with 1000 plus parameters. The operator can create his own recipes/operations/phases, create one batch and download it from HMI to PLC before clicking "batch run" button. It works pretty well. For the HMI which does not support Database connection, I would write the data to txt files with the same structure as a SQL Server table. Then the rest job on mapping and downloading data is the same.

Both approaches mentioned above utilize VB.

For this kind of stuff we've been using Wago PLC's (CoDeSys) which can read and write directly to SQL on the one hand and have Ethernet/IP support on the other. PM me if you want more details.

Good Luck,

Yosi

Thanks for all of the replies. To answer kamenges' question, I have used the SLC500 family a lot, but this is my first ControlLogix project from scratch. We have a lot of ControlLogix parts we salvaged from an automated welding machine we bought at auction a few years back. I dived into that machine pretty heavily at the time to try and adapt it to our parts, but we decided it didn't match our way of thinking.

Anyway, I have built the UDT with the job number/part number as a DINT member of the UDT. I have an array built with 1000 elements to play it make sure I have enough for growth.

I have a PanelView Plus 1250 we salvaged from the same welding machine for my HMI. I was never able to connect to the old program on it because it was built with an earlier version that didn't support uploading the program back to the PC. I have built the user interfaces for Quartech 2800s for SLC500s, Ultra 100 and Ultra 3000 drives, and I've done a lot of UI work with Access databases.

If the data can be stored in the array and referenced by the part number DINT from the HMI, then I'd like to hold off on developing an external app. I guess I'm at the point where I don't understand how that part number selected in the HMI propagates the values into the correct tags in the motion instructions, which I think is where daba was going.


Once it's selected in the HMI, how is the search done on the PLC side, or is this a "recipe" that can be managed by the PanelView Plus 1250?

If I understand what you're trying to achieve, what I'd do is:

- Assume your UDT is called RECIPE. You have a tag called, e.g. Recipes of type RECIPE[1000]. So Recipes[0] through Recipes[1000] is where all the data from the recipes is stored
- Also create a tag called Current_Recipe of type RECIPE (not an array)
- When you select a different recipe on the HMI, you change the value of a tag called, e.g. New_Recipe (DINT)
- When New_Recipe changes, execute this instruction: COP Recipes[New_Recipe] Current_Recipe 1. This copies all the data from the array item specified by New_Recipe into the Current_Recipe tag.
- Map all of your motion instructions to Current_Recipe values

I did a job similar to this last year. The other thing that I did was to add a string to the RECIPE UDT for a description. That way, on the HMI, when you're selecting a recipe it can look like this:

0: Recipe 123
1: Recipe ABC
2: Recipe XYZ
3: ...

Instead of just entering a number from 1-1000 and having to know what's what. But then I only had 100 recipes, not 1000, so maybe selection by number is better for your application. Horses for courses I guess

The PV+ 1250 does have a recipe manager. I've never used it so I don't know how well it works or how easy it is to set up. Also, unless you do something to get them off of it, the recipe values will be present in the HMI only (as far as I have been able to tell). Just a heads up.

If you decide to do this in the plc the best way to do this without bringing your plc to it's knees is to allow the operator to enter a part number at the HMI. If this value is non-zero, it triggers the following psuedo-code:

IF (HMI_Recipe <> 0) THEN

 

  IF RecipeArray[Index].PartNumber = HMI_Recipe

    COP(RecipeArray[Index], CurrentRecipe, 1)

    HMI_Recipe = 0

  END_IF



  Index = Index + 1



END_IF



IF (INDEX > 999) THEN

  RecipeNotFound = 1

  HMI_Recipe = 0

END_IF



IF (HMI_Recipe=0) THEN

   Index = 0

END_IF

Or some such. The good thing is only one compare cycle is made every scan so the search has minimal impact on the scan time of the plc. The bad thing is only one compare is made every scan so it will take you ScanTime * ArraySize seconds to complete a full scan of the array if a match isn't found.

Assuming the values in the recipe can be used directly in the motion instructions or other locations in the program you can use the CurrentRecipe members directly. If not, you may need to scale them and put them into other tags for use in the program.

Hope this helps.
Keith

kamenges said:

Or some such. The good thing is only one compare cycle is made every scan so the search has minimal impact on the scan time of the plc. The bad thing is only one compare is made every scan so it will take you ScanTime * ArraySize seconds to complete a full scan of the array if a match isn't found.

Click to expand...

If an FSC instruction is used to locate the data it could be programmed in NUMERIC mode to test a fixed number of elements on each scan - a compromise between scan time impact and latency.

Just throwing out for consideration:

• do a binary or quicksort search to speed up the process, if time becomes an issue
• compress all the non-zero job numbers down to the lowest array elements* then search until found or a value of zero is read (end of file) - to avoid searching empty data

* this would only be done when job numbers are added or removed

Ok, it's been awhile since I've been able to get back to this part of the project. Most of the rest of the control is designed, so I have a clearer picture of what I want to do. I have tried using Recipe Plus on the HMI, but despite the fact that it's ridiculously cumbersome to operate, it is limited to 500 Units, and I'm going to need more than that.

I looked into trying to apply what a few of you have suggested. While I understand it conceptually, as a MS-Access guy, I don't know some of the particulars.

@ASF recommended the UDT route, but I don't know what control would lend itself the best to selecting the recipe. In Access, I would use a combo box which is a drop-down that would list all of the possible values based on a query, and then once the user picked which one they wanted, that would change the value in the table, or activate code, etc. I tried to see if there was something comparable, like the Control List, but I wasn't sure if that was the right control, or how to set it up properly. Is there a way to populate a list that they can pick from? Is there a way to make that list searchable, or would they have to scroll through all 1000 entries? If they just type it into a numeric input control, how do I validate that they job number is a valid one? If it's a new one, how do I allow them to create a new entry every time they get a new part number, which is every week.

I liked @Kamenges' use of code to scan through the array and find the correct record since the operator won't have the index number, and all of the job numbers are four digits and not sequential. They will have to be able to select the right one based on that job number. It's very close to the visual basic I've used with Access. However, I haven't found where to write and how to execute it in the HMI. Is this done with macros, or something else?

Thanks again for all of your help. I have one of those bosses that has no clue what it takes to create something like this, so he has little patience for the amount of effort and time it requires to really make a professional control and interface. I appreciate your guidance in helping me get there.

You can use AdvancedHMI to do just this. If you have an Access database, you can create a Data Source from it within Visual Studio. Once your data source is created, you can set the field you want to be used as the drop down box and drag it onto the form.

You would then add an EthernetIPforCLXCom driver to the form and set the IP Address of your ControlLogix.

From there, you can double click the drop down box to get back to the VB code, get the values form the data source, then use the controllogix driver to write them to the PLC:

EthernetIPforCLXCom1.Write("MyTag",MyValue)

If you want to give this a try, I can give you more details on reading the data from the data source (Access database).

Over all you will end up with about a dozen lines of VB code.