OpenPDC to OpenPDC communication

I confirmed that both publishers are running, I see “False” in the “Subscriber Connected” section and 0’s in everything else. Save the “Subscriber Authenticated” section which also reads “False” on both PDCs. It is likely you are right that this is a networking issue, the error log has the same error over and over again which displays as follows:

"Data subscriber encountered an exception while attempting command channel publisher connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

I am on the same network with both PDCs…so a firewall shouldn’t be the issue…

Thanks,
Tyler

That error actually does suggest that there is a firewall blocking the connection. This doesn’t necessarily mean that there is a firewall between the two PDC systems if IPs or routing tables are wrong. However, there is a firewall that exists by default on every Windows system. You may want to check the Windows Firewall on each of the PDC systems. You can open it up by creating an inbound rule to allow connections to either openPDC.exe or TCP port 6165.

This worked perfectly! The PDCs are now connected and I can see a real-time graph of PMUA connected to PDC1 on PDC2. I cannot however use the historian playback utility to generate a file from PDC2 from the data colleceted from said PMUA. Any thoughts?

Thanks
Tyler

Internal subscriptions are not configured to archive data by default. All you should need to do is edit the device configuration for the internal subscription and set the historian. For example, in the openPDC Manager on the system running PDC1…

  1. Navigate to “Inputs > Browse Input devices”.
  2. Locate PDC2 in the list and click on its acronym to be taken to the Manage Device Configuration page.
  3. Go to the fourth input field in the column on the right and select a historian from the combo box located there.
  4. Click the “Save” button at the bottom right.

Thanks,
Stephen

I completed the steps above, and this fixed the issue. Thank you!

I had another inquiry. If, let’s say, I have 4 PMUs connected to PDC1 (PMUs A-D) and I only want PMUs A-C to report through to PDC2. Is there a way to facilitate this?

Thanks
Tyler

Yes, there are two ways to facilitate this.


The first way is to keep the metadata, but cut off the data flow. This will stop the real-time data from PMUD while still making it possible to browse to the PMUD device and see its measurements. Normally, if you don’t want the data, you probably don’t want the metadata either, but this can be useful if you’re frequently changing the data stream to receive only the data that is relevant to the task at hand. To do this, you would modify the OutputMeasurements parameter in the connection string. For example…

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ AND Device NOT IN (‘PDC1!PMUD’, ‘PDC1!PMUE’) }

You can also change the query to specify only the list of devices from which you want to receive data.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ AND Device IN (‘PDC1!PMUA’, ‘PDC1!PMUB’, ‘PDC1!PMUC’) }


The second way tells the server not to send the metadata across. The subscriber will be effectively unaware that the device exists. Its data won’t be transmitted to the subscriber, and you won’t be able to browse to it in the openPDC Manager on the subscriber system. For this method, you need to add a metadataFilters property to the connection string.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ }; metadataFilters={ FILTER DeviceDetail WHERE Acronym NOT IN (‘PMUD’, ‘PMUE’) }

Likewise, this syntax can be modified to specify only the devices you would like to receive data from.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ }; metadataFilters={ FILTER DeviceDetail WHERE Acronym IN (‘PMUA’, ‘PMUB’, ‘PMUC’) }


Note that using the first method, I specified device acronyms as they appear in the subscriber (PDC1!PMUA). Using the second method, I specified device acronyms as they appear in the publisher (PMUA). This difference was intentional because the MetadataFilters parameter gets transmitted to the publisher before being processed whereas the OutputMeasurements parameter is directly processed by the subscriber.

Stephen,

Everything is working perfectly now! I very much appreciate all of your help with this project!

Tyler

Stephen,

I am now encountering an issue with taking this project live. Previously I was working with a lab “proof-of-concept” version. I am now working with two field PDCs which are on separate networks.

The issue I am encountering is that PDC1 has full access to the data streams of PDC2 (and the devices connected directly to it). However, PDC2 does not see any data from PDC1. I see “True” in the subscriber connected however there is no data coming through. Any thoughts?

Thanks
Tyler

Tyler,

It may be that the subscriber on PDC2 is encountering errors when processing data from PDC1. There is a file called ErrorLog.txt in the openPDC installation directory. Scroll all the way to the bottom of the file to find the latest errors.

Also, can you tell me whether PDC1’s devices can be viewed in the “Browse Input Devices” page of the openPDC Manager on PDC2?

Thanks,
Stephen

Hi Stephen,

Thanks for the response. I can confirm that in the “Browse Input Devices” page PDC2 can in fact see the input device for PDC1. The status flags show that the subscriber is connected (Subscriber connected = True) however all other values read as 0s.

In the error log the following is the most recent error listed:

---- Stack Trace ----
GSF.Communication.TcpClient.ProcessConnect(connectState As ConnectState)
openPDC.exe: N 00171

(Outer Exception)
Date and Time: 8/17/2016 1:45:46 PM
Machine Name: redacted
Machine IP: redacted
Machine OS: Microsoft Windows NT 6.1.7601 Service Pack 1

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.1.120.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.1.120.0
Assembly Build Date: 7/30/2015 9:36:46 AM
.Net Runtime Version: 4.0.30319.18444

Exception Source:
Exception Type: System.InvalidOperationException
Exception Message: Data subscriber encountered an exception while attempting command channel publisher connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

In this, where “redacted” shows up I have edited that so as not to divulge our customers information. Any thoughts?

Tyler

First thing is, that error is too old to be relevant. If that error were still occurring, the subscriber would be attempting to reconnect every 35 seconds or so. The fact that the most recent error is from several days ago indicates this is not still happening.

I’m guessing the subscriber is connected, but it’s simply not subscribing to anything. Check to make sure PDC1’s devices have measurements when you browse to them on PDC2. Also, have you modified the OutputMeasurements parameter of the connection string for this subscription? It’s possible to modify that filter in such a way that it returns no results, which would cause the subscriber to subscribe to nothing.

Thanks,
Stephen

I didn’t even notice the error date, sorry about that. It is odd that the error has not been recurring, since the session still returns no measurements.

When I go to the “Graph Measurements” tab on PDC2 I can see that the PMU does have measurements (e.g. Frequency, Phase Angle, etc.) However they are all just returning 0s.

I have not modified the outputmeasurements parameter. I completed the setup as prescribed by our previous conversations on this topic. I am a little lost on what is happening now.

Tyler

So it sounds like the subscriber is subscribing to data, but the data is all zeros? I’ve never heard of that happening before. Would you be able to provide screenshots of the Graph Measurements screen from both PDCs for comparison? Pick the same frequency measurement on both so we can see the difference.

Thanks,
Stephen

I will get those for you shortly. Quick question…PDC1 does have database authentication and login credentials…would this impact it at all?

Tyler

No, I don’t think that would make a difference.

Stephen,

Here are the pictures of the graph measurements screen.

PDC1:

PDC2:

I have selected the station frequency as the measurement to be compared.

Okay, like I originally thought, it looks like it’s not subscribing to the data from PDC1. Here are some things you can check.


When the subscriber connects to the publisher, you should see some messages in the openPDC Console on the publisher system that look similar to the following.

[INTERNAL!DATAPUBLISHER] Start time sent to swills-desk.gpa.gridprotectionalliance.org ([::ffff:127.0.0.1]:46925).
[INTERNAL!DATAPUBLISHER] Client subscribed as compact unsynchronized with 138 signals.
[INTERNAL!DATAPUBLISHER] Received meta-data refresh request from swills-desk.gpa.gridprotectionalliance.org ([::ffff:127.0.0.1]:46925), preparing response...
[INTERNAL!DATAPUBLISHER] 258 records spanning 4 tables of meta-data prepared in 19 milliseconds, sending response to swills-desk.gpa.gridprotectionalliance.org ([::ffff:127.0.0.1]:46925)...

First, launch the openPDC Console on PDC1. Next, initialize the subscriber on PDC2. You should see the messages appear in the console on PDC1. Pay particular attention to the message that describes the number of signals the client subscribed to. If the message says it subscribed to 0 signals, then we know that it’s a problem with how the subscriber is evaluating the filter string in the OutputMeasurements connection string parameter.


You can query the database to determine what measurements the subscriber thinks it’s subscribing to. On PDC2, use the Browse Input Devices page, find and click on the subscriber device, and look at the connection string. At the end of that string, there should be a connection string parameter that defines the measurements the subscriber is subscribing to. It should look like this.

outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = 'GatewayTransport' }

We can convert this string to a database query by replacing “FILTER ActiveMeasurements” with “SELECT * FROM ActiveMeasurement”. Note that the filter expression uses the plural ActiveMeasurements while the database uses the singular ActiveMeasurement.

SELECT * FROM ActiveMeasurement WHERE Protocol = 'GatewayTransport'

Execute that query against the database to get the list of measurements.


The next step would be to determine if the measurements returned by the subscriber query actually exist on the publisher, but we’ll start with this. If the publisher claims that the subscriber is subscribing to more than 0 signals, then we’re barking up the wrong tree. If the query returns no results, then we need to figure out why.

Thanks,
Stephen

Stephen,

I am a bit confused on the process of querying the database. Am I supposed to put the query command into the console or should I literally replace it in the connection string and allow it to run from there? Thanks!

Tyler

What database type are you using? SQLite?

Stephen,

Yes the database is SQlite.