Tag events, gateway events, library scripts

Ignition
, ,
1

In a previous topic there was an issue mentioned on the best way to run a script for a specific event change. On tag change there needs to be a database write, which I have been informed is quite slow and can bog down the system. These 8 tags change at random, and no less than every 6 hours. So would the best solution be:

  1. Writing to a database using the built in tag event script.

  2. Writing to the database using the Gateway events script.

  3. Using project library and writing a script that is called when the tag event script is called.

2

Never do this... there are only 3, iirc, threads for tag event scripts. Tag even scripts must execute sub 10ms so that it doesn't cause issues with other parts of the system.

This is the way to do things like this. Write a project library script do the actual data logging, and call it in the Gateway even script as a single line.

This isn't like the others. The reason for doing a project library script isn't speed, it's code scoping. I don't fully understand it, but I've learned that sometimes scripts in tag events don't understand certain internal functions unless you import them. This can be mitigated by calling out to a project library script where the scope is proper.

So to give you the full answer, use a gateway even script that calls a project library script. This will help you avoid any potential scoping issues, plus when you need to troubleshoot, it's easier to do a single call in the script console rather than reproducing all the logic every time.

1 Like
3

There's also

  1. Write to the database through the store and forward system in a tag event script, typically using system.db.runSFPrepUpdate(). That will very quickly queue the database operation for eventual completion.
3 Likes
4

So I have configured my Gateway Event for a tag Change. However I have noticed that when the tag changes it writes to the Database 3 times even though the tag only changes once.

	# Retrieve the current values of each variable from their respective tags
paths = [
    "[default]CR Assembly/MDC15/PartSpecificTags/TestTag",
    "[default]CR Assembly/MDC15/PartSpecificTags/StartTime",
    "[default]CR Assembly/MDC15/PartSpecificTags/TempGoodPcs",
    "[default]CR Assembly/MDC15/PartSpecificTags/TempMissingPin",
    "[default]CR Assembly/MDC15/PartSpecificTags/TempPinLoad",
    "[default]CR Assembly/MDC15/PartSpecificTags/TempPlugGage",
    "[default]CR Assembly/MDC15/PartSpecificTags/TempRingGage"
]

data = system.tag.readBlocking(paths)
total_parts = sum(item.value for item in data[2:7])
total_rejects = sum(item.value for item in data[3:7])


params = {
    "PartNumber": data[0].value,
    "StartTime": data[1].value,
    "EndTime": system.date.now(),
    "GoodPcs": data[2].value,
    "MissingPin": data[3].value,
    "PinLoad": data[4].value,
    "PlugGage": data[5].value,
    "RingGage": data[6].value,
    "TotalPartsRan": total_parts,
    "TotalRejects": total_rejects
}

# Run the named query with the parameters
system.db.runNamedQuery("Jacks_Project","TestQueryForReport", params)
        # Reset tracking variables for the new part run
start_time = system.date.now()
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/StartTime", start_time)  # Update the Start Time tag for the new part run
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/TempGoodPcs", 0)  # Reset GoodPcs
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/TempMissingPin", 0)  # Reset MissingPin
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/TempPinLoad", 0)  # Reset PinLoad
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/TempPlugGage", 0)  # Reset PlugGage
system.tag.writeBlocking("[default]CR Assembly/MDC15/PartSpecificTags/TempRingGage", 0)  # Reset RingGage

Above is the code that is called when a tag is reset.

Is there any way to track why it's doing this?

5

Not sure what would cause it to be executed three times (outside of three changes). But I also don't know how you have configured the event. Also, you are not guarding against initial change, which might be an issue for you as well.

I can, however, tell you that the writeBlocking() calls should be consolidated.

system.tag.writeBlocking(paths[1:], [start_time,0,0,0,0,0])
2 Likes
6

I have the gateway tag change triggers set to the Value only, and I only have the Machine Specific tag path monitored. There is an error in our PLC System right now that might be causing the error so I will continue to monitor that.

image
image1020×792 43 KB

Thanks for this, I don't know why it slipped my mind the first time.

7

If the logic is the same for all those tag change scripts, you could probably merge all those events into just one.
You should have access to the path of the tag that triggered the event, so you can build the paths of the necessary tags from that.

2 Likes