When system.tag.write is used to write new value to a UDT instance, the value changed gateway script never fires. However, on the next scan, the new value is contained in previousValue of the value changed script.
I would expect system.tag.write would trigger the value changed script with the new value as the currentValue.
/c
Message: Dispatching 0 change notifications and 1 write notifications.
Time: Tue Mar 22 7:36:58PM
Severity: DEBUG
Logger: ignition.TagManager.Gateway
TRACE [TagManager-AWT-EventQueue-2] Subscribing to ‘MacLeanFogg/Context/Users/4756ADEC/PrinterId’, property: Value
UserClass.getTag(‘PrinterId’) = ‘2112’
UserClass.setTag(‘PrinterId’,‘jkhll’)
DEBUG [Writes-AWT-EventQueue-2] Writing jkhll to “[default]MacLeanFogg/Context/Users/4756ADEC/PrinterId”
TRACE [Writes-AWT-EventQueue-2] Write [default]MacLeanFogg/Context/Users/4756ADEC/PrinterId=jkhll pending. ID=6
DEBUG [Writes-TagManager-thread-1] Received 1 write finished notification(s): [WriteOpDone[id=6, result=[GOOD]]]
TRACE [Writes-TagManager-thread-1] Write 6 finished with result [GOOD]
DEBUG [Gateway-TagManager-thread-1] Dispatching 0 change notifications and 1 write notifications.
{‘current’: [2112, Good, Tue Mar 22 19:44:46 CDT 2016], ‘previous’: [jkhll, Good, Tue Mar 22 19:44:31 CDT 2016], ‘initial’: False, ‘tagPath’: u’[default]MacLeanFogg/Context/Users/4756ADEC/PrinterId’, ‘missedEvents’: False, ‘type’: ‘TAG_CHANGE_EVENT’}
DEBUG [Gateway-TagManager-thread-1] Received 1 value changes: [MacLeanFogg/Context/Users/4756ADEC/PrinterId=[2112, Good, Tue Mar 22 19:44:46 CDT 2016]]
I forgot to mention that this is a SQL Query tag.
[quote=“cmisztur2”]I forgot to mention that this is a SQL Query tag.[/quote]Well, there’s your problem. The SQL query is run at every scan and the tag change evaluated right after. So would an expression tag. Personally, I think it’s a design flaw that Ignition lets you write to such tags.
I created an expression tag on the Default 1000ms scan class and still am missing a change notification.
You misunderstand my point. It’s not going to work and it’s not a bug. Ignition executes tags on a schedule determined by the scan class. For Query and Expression tags, it executes the query or expression, compares the result against the tag’s current value, and generates the tag change event if they differ. They will only generate tag change events right after they execute. These tags are not supposed to be written to. If there’s any bug, it’s Ignition letting you write to these tags at all. { Other than Client tags – they don’t have scan classes. }
Why are you trying to do this? Anything you write will be replaced by the Query/Expression result at every scan.
Phil is correct, you shouldn’t/can’t write to Expression/DB tags, and we should be returning a bad quality instead of letting the write go through even though it basically has no effect.
In cases like this, you must send your data to the point where the query/expression gets the data you want. In your case, I think you should be updating the database, not writing to this tag. Then the tag will follow on the next scan.
I want writing the tag to execute a SQL update.
That's it.
[quote=“cmisztur2”]I want writing the tag to execute a SQL update.[/quote]Ignition can’t automagically change a Select query into an Update statement. The script that writes the tag just needs to run an update query instead.
Then this is a feature request for a SQL CRUD tag.