Hi,
I have a system which send the C37-118-2005 to openPDC as input stream. Can I configure PDC to send the same data as C37-118-2011 as an output steam. Thanks in advance.
Rabi
You certainly can, yes.
However, if you are sending data between two openPDCs, I recommend using IEEE 2664 (STTP) for simplicity. Then you can still create your C37.118-2001 output stream as desired.
Navigate to “Inputs > Subscription Based Inputs > Create Internal Subscription” on the receiving PDC to setup an STTP connection that will receive all data from the source PDC.
I suggest unchecking “Use Source Prefix” if this is going to be the only input stream.
Thanks!
Ritchie
Thank you ritchiecarroll for the reply.
I was trying to do the setup but I think I missed something. Let me share the details of my setup.
Our input is from SEL 411L to openPDC, which is streaming correctly (UDP connection is local in LAN).
Now, in our output stream, we are trying to send the data to WAN. We are trying to set it up as a TCP connection. But I am not sure how can we have UDP as the input using LAN connection and TCP as the output PDC to WAN.
Thanks,
Rabi Kar.
Sure thing. If you have an existing PMU input in the openPDC that is operational, regardless of protocol (transport, phasor, or otherwise), start the openPDC Manager UI application and navigate to “Outputs > Concentrator Output Streams”. Click the “Add New (+)” button on the middle, right side of the screen, and type in a name for the output in the “Acronym” field, e.g., “TESTOUT”. From the “Protocol” drop-down, select “IEEE C37.118-2011”. Next, click the icon that looks like three-blocks with a pencil that is to the right of the TCP Channel text box, enter the desired port number for the TCP connection, the default 4712 is fine if nothing else on the system is already listening on that port, then click “Save”. Enter “5” into the “Lag Time” and “Lead Time” fields, representing +/-5 seconds of time tolerance for measurements sorted into this output stream. Click the “Enabled” checkbox, then click the “Save” button on the middle, right side of the screen.
You now have defined a new output stream in the IEEE C37.118-20011 protocol format listening on TCP port 4712.
Next, you need to add your existing PMU to the output stream. In the table of outputs at the bottom of the screen, make sure “TESTOUT” is the selected record. Note: it may be necessary to navigate to the last page if there are multiple pages of output streams defined, newest output will always be the last record.
With the “TESTOUT” record selected, click the “Device Wizard” link in the table row. From the pop-up list of devices, select your input PMU (the one reporting via UDP and IEEE C37.118-2005, for example). At the bottom left, select if you want analogs and digitals from the input to be included in the output. Finally. with desired devices selected for the output stream, click the “Add Selected” button. The screen will now show a summary of devices that exist in the output stream. Click the green “back arrow” at the top-right of the manage application to go back to the output stream setup.
Verifying the “TESTOUT” record is selected, you can now click “Initialize” to start the output stream. You can now connect to the “IEEE C37.118-2011” output stream, e.g., with a tool like PMU Connection Tester.
Thanks,
Ritchie
Thank you ritchiecarroll for the reply.
I tried the steps you provided. With this, I can detect the phasor variables, but I cannot see any data. I have attached the screenshot of my output from the PMU tester and my settings. Since I can send only one figure, I am adding the settings pic in another reply.
It is possible that the timestamps in the incoming device stream are not synchronized to GPS, or your local clock time is way off. In either case, you can set the output stream to use the PMU timestamps as the real-time clock source and generally ignore bad time.
To do this, on the output stream screen on the openPDC Manager, with the “TESTOUT” device selected, open the “Advanced Properties” and check or uncheck the following settings accordingly:
- Disable “Perform Timestamp Reasonability Check”
- Disable “Use Local Clock as Real-time”
- Enable “Ignore Bad Timestamps”
- Enable “Round to Nearest Timestamp”
Then click the “Save” and “Initialize” buttons.
Let me know if that helps.
Thanks,
Ritchie
FYI - in your images above, the timestamp on incoming data has an hour of 16:00 and the PMU connection tester shows an hour of 15:00, so it is likely that there is a device / local clock discrepancy of at least one hour. The settings changes I suggested above should assist with making sure data is published even if timestamps are otherwise considered unreasonable.
In a production system where all incoming time is measured according to GPS, these default reasonability settings make more sense - not always so much in a test environment.
Thanks,
Ritchie
Yes, I see that. By ignoring the errors in advanced settings, I can send out data correctly, and I see that both times are synchronized. The time shown is UTC time, which comes from the SEL satellite clock.
I will need to check why, in the previous settings, the time is one hour different.
Thank you so much for your help.
Rabi Kar.
Hi Ritchie,
I was trying to connect a SEL to OpenPDC using UDP connection. I can get data in PMU connection tester, see the screenshot below,
But I cannot get the data in OpenPDC.
The UDP port is setup at 4723. I am not sure what I am missing. I have setup the input connection setup in OpenPDC.
Thank you,
Rabi Kar.
Hi Rabi,
Did you disconnect PMU Connection Tester before attempting the connection in openPDC? Also, can you check the ErrorLog.txt file or the openPDC Console for errors?
Thanks,
Stephen
Hi Stephen,
Yes I did disconnect the PMU Connection Tester before openPDC connection. I do not see any error in openPDC console, please find tha screenshot below,
Can you type the list PDC_4723 command into openPDC Console and share the output? That should help us understand if openPDC thinks it’s receiving anything.
Hi Stephen,
I checked one thing, when I setup openPDC and keep it running, the PMU connection tester cannot connect any more. This means the openPDC is somehow connected to the PMU (SEL relay), but is unable to receive any data from the PMU. I am not sure what can be the reason for the system to behave like this.
Thanks,
Rabi Kar.
Hi Rabi,
Both the PMU and the openPDC are merely listening on UDP port 4723. It is up to the PMU to send UDP packets to that port. There is no connection being made, but only one application can open that port for listening at any given time. That’s why I asked whether you disconnected the PMU Connection Tester.
Given that, it simply doesn’t make sense that the PMU Connection Tester is able to receive data and the openPDC is not. I was hoping to see more of the output from list PDC_4723 to help you diagnose what might be going on. Can you share more of the output?
Thanks,
Stephen
Hi Stephen,
Is there a way to export the output into a text? Once I enter " list PDC_4723" I just get that info in the screen.
Let me know how can I get more details.
Thanks,
Rabi Kar.
Normally there is a scrollbar on the right side, and you can right-click the title bar to navigate to Edit > Mark so you can copy/paste the text on the console. You should also be able to see the output in StatusLog.txt after issuing the list PDC_4723 command.
