I’m currently trying to run a project script from a value changed event of a UDT tag. The function that I’m trying to run comes from a util script in the projects script library that simply logs a message to the logger. However when I try to call the function from my UDT I keep getting an error that says " ‘project’ is not defined". This is my code:
def valueChanged(tagPath, previousValue, currentValue, initialChange, missedEvents)
line = “[.]Line”
if(previousValue.value == 0 and currentValue.value == 1):
project.flashCalibration.saveFlashCalibrationReport(line)
else:
msg = line + ‘awaiting calibration’
project.util.logMessage(line,msg,0)
Ok I'll bite, what did Tag Events ever do to you? Almost every project I've ever seen has Tag Event scripts and the only issues I've seen are because of bad scripting that blocks the thread.
When scripting across many tags, each gets its own copy of the code. To minimize per-tag code for maintainability, you must move it a shared script. But editing or adding a shared script restarts all gateway scripts across all projects, and causes every client to at least show an update (if not auto-updating). This is astonishingly disruptive. Shared scripts should be locked down to just the most common, best tested code, and placed under some kind of change management. Gateway tag change scripts, as opposed to tag events, can subscribe to many tags, can be enabled and disabled for all quite conveniently, and can be individually enabled/disabled simply by editing the subscription list. And they can call project script instead of having to call shared scripts. Disabling a project disables all of its event scripts. No way to do such a thing with tag events, short of including some code in every one of them to check a common flag somewhere. With gateway events, you can even have multiple projects subscribe to common tags, enabling and disabling in various ways, all without disrupting each other.
Putting project-specific code in shared scripts just to use tag events in a somewhat maintainable way is the height of foolishness, especially when a better alternative is available. If you have a trivial single project in your gateway, have at it.
On a more positive note, if you ever make it possible to define custom methods for UDTs, callable from members’ events and expressions in a natural, object-like way, I’ll become a fan.