Resource management ignition

Greetings all,

I am working on an inventory management project that will signal material handlers when a machine needs more raw material brought from the storage locations to the line for production. Currently, I have one machine setup for this using scripts and memory tags. When the PLC tag triggers that a machine cycle has ran, I run a script to see what part number was ran and how many. I have a tag folder named for each part number, and it is filled with memory tags for each component of that part. Some machines run more than one part number per cycle and all machines have 3-12 components per part. Anyway, the script pulls the current count from the memory tag of each component for each part number that was ran, it then decrements it by the number of that component that is consumed each cycle. Then a script written on those memory tags triggers each value change to compare the current value to see if it is equal to or below the refill quantity. If it is below the refill quantity, then it turns on a memory tag for replenishment of that part. The material handler can see what replenish tags are on and bring those components to the line. When he scans in the components, I parse the label to find the part number and quantity and add them back to the memory tag values which resets the replenish tags.

My question is, will adding 100s more of these memory tags with scripts degrade ignition performance? Should I instead be putting all this into a SQL DB table and running scripts to update the DB? I am torn on if all the sql lookups and updates would be more performance degrading than running scripts.

Thoughts?

Thanks
Tom

First major thing, make sure all of these scripts are executing in a Gateway Tag Change Script, not a Tag Value Change Event.

Second, I would see if you could keep track of how many parts are left on the machine PLC. You would need to store recipe information on the machine but then you let the machine subtract the numbers from the stock value as it consumes them and just monitor those numbers in Ignition to alert your material handlers. Ignition would only add to the value in the PLC whenever components are restocked.

For keeping with your current method:

I would start by condensing/reducing how many tags you are using per machine by configuring a dataset tag per machine that contains the component Id ,remaining stock for that machine, restock limit, and a requiresRestock boolean. It should contain every possible component the machine could ever consume.

This would net you 1 dataset tag per machine, which should be less overhead than several folders of several tags per machine.

Store the Part makeup(how many of what component go into what part) in a DB table and load it into static memory tags on gateway startup and a manual refresh trigger, so you can update it on the fly if your recipes change. You can reference that tag data whenever you need to determine how many components to subtract from the remaining stock on a machine.

This nets you 1 + how ever many tags you have to store recipe information (probably can store it all in 1) tag reads and 1 tag write per machine per script execution.

When you run your script on cycle completion, you can loop though the dataset tag for the respective machine and do all your normal math/comparisons for each component but instead of writing to multiple tags, you just update the values in the dataset you read from and write it back to the tag.

Instead of having the material handler look at separate boolean tags in a folder you can create a view or window that looks at the 'restockRequired' column for a machine and highlights or lists the components that need to be restocked for that machine.

1 Like

Ryan,

Thank you for your suggestions. I was already considering a DB with the part/component makeup for this project instead of folders last night. I figured moving all of that out of ignition would be beneficial. My only concern with storing the component values in the PLC vs Memory tags was that the counts would be lost if there was a power outage, or the machine was turned off for maintenance. I believe the memory tags are retentive and would hold the value for me.

Thanks
Tom

Most PLC's have retentive memory registers, so you shouldn't have to worry about losing the count of components left on the PLC on power off/cycle.

I personally like having the PLC be the source of truth in these systems, at least for consumption, as they are the ones directly controlling what gets used and when.

If you still aren't comfortable with having the PLC store that info then memory tags should be fine.