Best way to clear the value for 42,000 tags?

Ignition
1

I have a lot of tags, nearly 42,000 that I would like to clear the value of before writing to them. These are memory tags with a mix of Integer, Boolean, String, and Float datatypes. Before I explain why let me lay out the design.

Note: I will probably end up mixing terms trying to explain without divulging any protected information. I am in the testing phase so these tags aren’t being written to the PLC, yet.

These tags make up the “recipe system”. I have block transactions set up to pull recipes from our SQL database to these tags.

image
image163×445 9.55 KB

There are 2 types of block items

Header 
This has 23 folders and each folder has Tag 1...99

image
image370×560 31 KB

Recipe_# 
There are 70 Recipes Recipe_1_ to Recipe_70_ each one has 14 folders with Tag 1..99

image
image359×380 17.9 KB

image
image371×379 13.5 KB

These are used in SQL-Bridge block transactions. There are triggers used to cascade from one block to the next. That works fine to write the tags that have records in the SQL database. It takes some time but that’s not a concern. My current solution is an Excel spreadsheet that uses VBA and RSLINX to write the values.

The header structure holds some basic data about the recipe. Each Recipe_# folder holds up to 99 steps for the recipe. However, not all 99 steps are used and the database only contains the records for defined steps. I.E. there aren’t blank placeholder records. Recipes can change from time to time and steps may be changed, removed, added.

If a recipe is changed and steps are removed the previous values don’t get cleared when the block transactions are performed.

Let's say Recipe 42 has 23 steps. A change come down and the recipe now only has 18 steps. The transaction will overwrite steps 1-18 but the tag values for 19-23 are not overwritten/cleared/erased/set to default as there is no record in the database for those steps.

They just don’t get written. I don’t see a way to have the block transaction “write default value if no record returned”. This functionality appears to be different than the options:

Set NULL tags values to default

set NULL DB values to default

as these appear to only perform their action if a record is returned with NULL values.

Due to the design by others previous to me there is no ‘end step’ defined for a recipe :hot_face: , the PLC just goes till it runs out of commands. This would mean the PLC would attempt to run steps 19-23 as there would be data.

My goal is to allow a “user” in Ignition to perform this entire procedure via 1 button if I’m not available. Ignition will also have the ability to view each recipe which will be new to them.

SOLUTIONS?

As I see it the only option available would be to create a script that iterates through all these tags and sets its value to the default value. This would probably be nested loops but I haven’t convinced myself this is right way.

edit:

It may be easier to add an ‘end step’. However, that requires many changes to the PLC, SQL, current “recipe builder”.

The logic that looks for the value = 0 to indicate end of recipe is “locked” in an AOI. While I change the AOI it will require a download which will require shutting down pretty much the entire facility.

Anybody got a better idea?

2

Not sure I fully understand, but you can create an iterative tag list and do a for tags in taglist loop to set the values.

But instead of all 42000 tags, why wouldn’t the operator just clear out the one recipe that’s changed?

3

Have you tested this with “set NULL DB values to default” turned on? I’m fairly certain that I tested this for a project and it did clear the values that had no results in the database.

4

edit: The operator may not know as if a recipe was removed then currently everything would “shift up”. I’m working through attempting to standardize this whole setup as there isn’t much structure or planning. A long time ago this was an Access “database” then was upgraded via copy/paste to SQL.

I swear that didn’t work the first time. It appears that perhaps there was a delay in the update on the tag browser?

5

Glad that it worked. I have a project planned for later this year that was planning to use it.

6

That seems like an awful lot of transactions to create and maintain that could be replaced by a single script function that does the same thing with parameterisation. I'm not a fan of SQL Bridge in general, but in this instance I think there is absolutely merit in not using it to keep it maintainable

4 Likes
7

I thought about using a script but then I may not be the one to maintain it in the future. Using the SQL-Bridge module does allow me to parameterize to some extent, or rather lay things out in a logical visual format that allows someone else to decipher without the need to know Python. The hard work is done. The structure and transactions for 99 possible recipes each with 99 steps is complete. This exceeds the current capability in the PLC.

There are really only 2 transactions. The Header group and the first recipe. After that it’s copy, paste, find, replace to create the rest.

In this case the SQL-Bridge allowed me to take something that would be ‘complex’ scripting and distill it into a some checkboxes and selections.

edit: Thinking about this, a script with parameterization would be a solution to copy the memory tags to the OPC tags. Allowing me to control when the tags are written to the PLC.

8

In general I agree with you, but I have run into more than one scenario where the person that will be responsible for long term maintenance prefers the graphical interface of the SQL-Bridge module instead of scripts and logging.

Slowly but surely changing that mindset, but for now having both options is helpful.