This project has moved. For the latest updates, please go here.

DynamicCalculator with one-second average inputs

Mar 25, 2013 at 6:22 PM
I am trying to create Dynamic-Calculator with two inputs: one-second average frequency (using GPA adapter), and one-second voltage phase angle slope average (my own adapter). The correct averages are seen in the historian and the graphs, with identical timestamps (second boundary). However, I cannot get the Dynamic Calculator to produce any output using these inputs; no errors of any kind, but no output either. I've tried setting the Dynamic Calculators Frames-Per-Second to either 1 or 30, with no change in behavior. Is there an parameter that could solve this?
Apr 1, 2013 at 6:56 PM
Does anyone have experience with one-second measurements; that is, two measurement streams, with values only present on the 'top-of-the-second' (average frequency, average phase angle slope). I am trying to use the DynamicCalculator to check certain required relationships.
Coordinator
Apr 2, 2013 at 6:32 PM
Hi patpentz,

I expect that the dynamic calculator should work fine with the one-second averagers. Try setting frames per second to 1, and also set lag time and lead time to something excessive like 5.

Stephen
Coordinator
Apr 2, 2013 at 6:33 PM
If the timestamps for your values are not perfectly aligned you can always write a custom action adapter and set the TrackLatestMeasurements property to true - especially if the closest measurement alignment can be a second or so away. When TrackLatestMeasurements is enabled, incoming values will be auto-populated in the "LatestMeasurements" collection (a property of all action adapters) with temporal measurements.

Temporal measurements have a valid life window that exists between the action adapters defined lag and lead times - that is, if the latest update to the temporal measurement value is outside this range the temporal measurement will return double.NaN as its value; otherwise if the value has been updated within the lag/lead time window the latest value will be returned.

In short, you can check the frame for your needed value and if any are missing use the "latest measurement" to fill in the gaps - especially useful for non-synchronized, periodic data - like SCADA values.
Coordinator
Apr 4, 2013 at 2:13 PM
FYI, I ran a test on this and was able to graph a calculated point based on average frequency inputs. I used the dynamic calculator with the settings I mentioned above.
Apr 8, 2013 at 3:43 PM
I'm still having problems with the second factor in the calculation. I am comparing average frequency as calculated by the OneSecondFrequencyAverager, which seems to push the values into the next second:
outMeasurement.Timestamp = frame.Timestamp + Ticks.PerSecond;
Is it correct that the 'filtered' Down Sampling creates the average value for all values within the period?

On the other hand, my slope average calculates the single final value in the first frame after the top-of-the-second; this value is inserted with a timestamp of the current truncated second. Perhaps at this time the average frequency for this timestamp is 'old history'.

Essentially the frequency averager pushes its values into the future, while my adapter currently pushes its value into the past (actually, usually the current frame timestamp if the zero-th frame). Would this lead to a mismatch of values/timestamps? The historian shows correct values for these measurements at the correct timestamps, but that is not a real-time view.

If this is more-or-less my problem, perhaps the 'track latest value' technique will solve the problem. Not so far, but I just started.
Coordinator
Apr 8, 2013 at 4:56 PM
You can think of the OneSecondFrequencyAverager as a concentrator. By setting FramesPerSecond to 1, the concentrator is configured to create one frame at the top of each second. All values that come in between two frames will be sorted "backwards"--that is, they will be sorted to the nearest frame whose timestamp is smaller (in the past) as compared to the timestamp of the measurement. Thus, the frame timestamp will always be at the top of each second, but will refer to the time that the calculation started as opposed to the time that the calculation finished. The timestamp conversion you quoted moves the timestamp forward to the point when the calculation finished.

Of course, it depends how your slope average calculator is written, but it sounds like it might be working fine. The current time truncated to the second should give you the timestamp of the latest average calculated by the OneSecondFrequencyAverager.
Coordinator
Apr 8, 2013 at 5:04 PM
Also note that measurements whose timestamps are aligned with the top of the second are sorted into the frame whose timestamp matches that of the measurement (not one that's in the past).
Apr 11, 2013 at 5:55 PM
after much agony, my generation of phase angle slopes, and comparison of such against frequency deviation from nominal, works as desired. Thanks to all, especially for the education! Now, once I get the PI input adapter to work as desired, I will be comparing those values against phasor data. Should be interesting, since the timestamps will be out of whack!