Sequence Component Calculation Abruptly Stopped

GPA Products openHistorian
1

Hi Ritchie,
Not sure what might be the reason, the sequence component calculations suddenly stopped working from today. They were working fine till yesterday. I had refreshed the Archive folder for openHistorian. After that it generated for almost 2 hours and then it stopped generating.
Thanks,
Datta

2

Could source device timestamps be far away from local time? Check the file Status.txt and look for details on bulk sequence adapter. The details there should show if adapters are receiving measurements as expected. You can paste details here I can help you analyze.

Thanks,
Ritchie

3

Hi Ritchie,
Please find below the Status of the Sequence Comps adapter below:

Status of IActionAdapter component 10, SEQUENCE_COMPS:

  •     Frames Per Second: 50*

  •  Lag Time / Lead Time: 5.000 / 3.000*

  •    Point Tag Template: IAM!{0}*
  • Alternate Tag Template: *
  • Signal Reference Template: IAM!{0}-CV*
  •  Description Template: {0} [{1}] measurement created for {2} [{3}].*
  • Device Acronym Template: *
  •    Output Signal Type: CALC*
  • Target Historian Acronym: PPA*
  • Source Measurement Table: ActiveMeasurements*
  •    Inputs per Adapter: 6*
  • Input Index Used for Name: 0*
  • Output Names per Adapter: 6*
  •              "PositiveSequenceMagnitude"*

  •              "PositiveSequenceAngle"*

  •              "NegativeSequenceMagnitude"*

  •              "NegativeSequenceAngle"*

  •              "ZeroSequenceMagnitude"*

  •              "ZeroSequenceAngle"*

Re-parse Connection String: True

  •  Original Data Member: ActionAdapters*

  • Config Reload Timeout: 10,000 ms*

  • Config Reload Attempts: 2*
    Database Connection String: Using

  • Total adapter components: 0*

  • Collection initialized: True*

  • Initialization timeout: 15000 milliseconds*

  • Current operational state: Enabled*

  •   Temporal processing: Unsupported*

  •   Data source defined: True*

  • Referenced data source: Iaon, 23 tables*

  • Data source table name: [internal]*

  •     Connection string: 5 key/value pairs*

  •  ForceCalcSignalType = True                                              *

  •      FramesPerSecond = 50                                                *

  •              LagTime = 5.0                                               *

  •             LeadTime = 3.0                                               *

  • InputMeasurementKeys = FILTER ActiveMeasurements WHERE SignalType LIKE...*

  • Respecting input demands: False*

  • Respecting output demands: False*

4

The thing that I found that the phase has once again be reassigned to the default positive sequence. Is that due to reason that once you initialise it again it reverts back to the default phase?
Is there a way to mitigate it so that it does not revert back to the default once it is initialised in between

5

Exactly when is the phase being replaced back to positive sequence?

If you are using a subscription, e.g., GEP or STTP, as your source - it will always replace local changes with those that exist at the source.

Your source data, the publisher, is considered to be the primary and in control of changes - the subscriber is considered subordinate, it takes and applies changes made at the publisher.

To make the changes “stick” you will need to make the changes at the publisher…

Thanks,
Ritchie

6

Could you please clarify what you meant by Publisher?

7

How is the data flow between your “data source” and “data sync” configured?

I presume your “data sync” is openHistorian - but what is the source? openPDC, a directly connected PMU?

If it is openPDC, then the connection between openHistorian and openPDC is usually a “subscription based connection” where the openPDC would be the “Data Publisher” and the openHistorian would be the “Data Subscriber”.

Ritchie