Script Initialization / Scoping Help

I programmed an event based system for logging data from PLC. PLC fires an ‘event’ that contains a code for event type and then data associated with that event type.

Currently I do this all in one global shared script file and a switch for calling the correct function for that event. I.E something like

def baseEvent(eventData):
if eventData[eventType] == 4: PartCreatedEvent(eventData)

I’m getting worried though because i’m up to about 20 events and production lines now rely on this to continue running and I want to make this a little more safe to work on as making an error in this file now when adding a new event could cause downtime.


I thought I could create one file with the base event, a dictionary of codes and event functions, and a registerEvent(code, event) function. But it looks like script doesn’t initialize until you actually call something from that script. So creating another file like so doesn’t work because the script never runs until something is called from it:

def partRejectedEvent()
print ‘omg!’

shared.eventPackage.baseEventScript.registerEvent(4, partRejectedEvent)

Anyone know a way to register functions into a main script file that doesn’t require main script file to be modified?

Don’t use tag events. Use a gateway tag change event, under a specific project. Monitor all similar tags from one event definition. Use project script modules instead of shared script modules. The gateway event should just call the function in the project script module.

In the project script module, use initialization code to look back into your database and preload a dictionary with the last logged event from each trigger. Project edits will cause the event to fire with initialChange true for each monitored tag, which will cause your project script module to be initialized first. Since it is possible to be a new value even on initialChange, always compare your event trigger value against the one stored in the dictionary to determine whether to log or not. After your DB insert succeeds, update the dictionary.

You really don’t want to be editing shared scripts in a big, multi-line, multi-project installation.

Consider using separate projects for each production line if logging volumes are large.

Thanks for the quick response.

What about when I add new events though? Say I want to add log_operator_pressed_button() wouldn’t I still have to modify the one central gateway tag change event script that if I made an error in could prevent all events from working?

First, don’t have the central script in a shared script module. Move it to a project script module (same project as the new event definition).

Second, do your editing in a copy of the script module, with another gateway tag change event configured to monitor just handful of tags that are safe to play with. Maybe even just memory tags that aren’t really part of a production line. Test all of your new code that way, including retesting it with prior functionality. When ready, edit the main tag event to point at the new function in the new project script module. You can delete the old script module at your convenience, or copy the new proven content into it to be your next playground.