Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X
Hello, I think I need some help configuring some Datalogger Trigger settings. I have a set of tags that I wish to record during a specific operation where the frequency of the logged data should match whenever the value of a single monitor tag changes.
I set up a condition-based trigger where under the general settings I configured the start and stop logging conditions to reflect the specific operation during which I wish to record data, and this behaves as expected. Since I only care about logging data when the value of a single tag changes, under the Logging Conditions menu, I set the 'Log on Static Interval' field to No and 'Log on Data Change' field to Yes. I set the Monitor Item ID to the tag whose value I want to drive the data logging, set the Monitor Item Update Rate to 1000 milliseconds (I am fine with checking the monitor tag's value once a second), and make sure there is no deadband type (because I wish to log any value change).
And somehow, when I check my database table, I am seeing as many as 20 logged entries in row where none of the logged data other than timestamp have changed their values? Any advice would be greatly appreciated!
Solved! Go to Solution.
This might be easier. First one sets up the triggers and the second one uses them. Only logs one time per rising transition
I might be off here but there can be a Start and a separate Stop trigger. Did you define a stop trigger?
I did define separate start and stop triggers. The datalogger DOES seem to respect these conditions, just not the 'Log on Data Change' condition.
Upon first glance, it didn't appear that my data was being logged at a regular interval, but when I started doing the math it actually appears that it is actually logging very consistently every 2.74 seconds.
What was the STOP criteria and is it being met immediately after the data changes and gets logged?
I know "Log on Data Change" should mean exactly that, but have you seen it work in the past?
I'm just spit-balling but I thought I remembered some sort of complication around that setting.
The stop criteria is a boolean tag that is not part of my recorded data changing from false to true. I have not seen the "Log on Data Change" option work as it sounds before, so you may right that it is more complicated than it seems.
I would look hard at the STOP criteria or even remove the Start and Stop, As I recall it will continue to log until Stop is met but the interaction with log on change could change that
I have a working one that is
(General Tab)
"Always Triggered"
(Logging Options)
Log on Static Interval = No
Log on Data Change = Yes
(Monitor Item)
Log All items = No
But its always on - I'm not turning it off and on via anything else, I removed the data I don't want via the SQL query later on in the process
Having said that, I do have a logging group called Triggers that are time based (every 5 minutes by the clock) and I use that group as a trigger for other groups because oddly enough the Start and Stop use the moment the log groups starts logging as the base for timing and not the minutes of the clock..
So essentially nesting triggers got me where I needed to be
Interesting! Thanks for the suggestions, I appreciate them. Out of curiosity, what exactly is your Triggers logging group doing? Is it updating a tag value that your other logging groups are using as a monitor tag?
This might be easier. First one sets up the triggers and the second one uses them. Only logs one time per rising transition
Thanks for sharing, that's a pretty creative way to trigger datalogging! It is kind of wild that we need to resort to doing something like that versus the software just behaving the way that it seems to imply it should though.
Yea, Already tried to get them to deal with that but not long after I figured that issue out, PTC (same VC that killed LogMeIn) bought Kepware and KepwareEX just stagnated after that. Support quality went downhill too as their efforts focused on Thingworks. So I'm not expecting any further improvements to KepwareEX.