This project has moved and is read-only. For the latest updates, please go here.

Unable to get data from Output Stream

Apr 26, 2011 at 5:07 PM

Hi,
I'm trying to setup an output stream but when I connect to it using PMU Connection Tester, I get no data.
I have followed the steps to create the output stream.
And to connect to it using the PMU Connection Tester.

But PMU Connection Tester shows nothing.

Thanks in advance,

Hugo.

Apr 27, 2011 at 8:27 AM
Edited Apr 27, 2011 at 8:28 AM

Hi Hugo,

When using the PMU Connection Tester do you at least get the Config Frame from the openPDC system? i.e. in the left hand pane called "Configuration Frame" you see the devices you have and the corresponding phasors if any?.

Try disabling your firewall temporary to see if the problem is related to firewall settings, if so adjust you firewall accordingly.

 

Best,

 

Moustafa

Apr 27, 2011 at 1:50 PM

Hi Moustafa,

Yes I can get the configuration frame.

And I can see the device and the corresponding phasors.

But still no data.

 

Thanks,

Hugo.

Apr 27, 2011 at 2:55 PM

Hi Hugo,

Good, getting the configuration frame is a good sign!

have you tried disabling the firewall? and then trying to connect?

The reason I am saying this, is that sometimes the configuration of the openPDC is correct, but certain system characteristics inhibit its normal operation.

if the firewall did not help then consider configuring you PDC output stream to be " Generous" i.e. not to have stringent requirements on the arrival of data from your devices and not to discard due to time errors etc, for example try:

Lag time=10, Lead Time 10, Auto Start Data Channel= Checked, Allow Sorts by Arrival= unchecked,  Allow Preemptive Publishing =Checked , Auto Publish Config Frame = Checked, Use local clock as real Time= unchecked, Ignore Bad Time Stamps =Checked.

if that works, then start optimizing your system, by lowering lag and lead time etc to see your systems tolerance.

if you are using Windows 2008 Server, then please note their could be problems with IPv4 and v6 on the PMU Connection Tester, for example on my Windows 2008 system  forcing IPv4 on the Connection Tester results in the connection Tester not connecting to the openPDC output stream, just as in your case. While using IPv6 on the Connection Tester works! (note I think IPv6 is defualt on the PMU connection Tester).

If all else fails then can you describe the characteristics of your systems, i.e. openPDC version, operating system version, language, how many PMUs etc. if possible.

 

Best Regards, 

 

Moustafa

 

Apr 27, 2011 at 3:23 PM

Hi Moustafa,

I forgot to say in the previous post that the firewall is disabled.

Also, the Output Stream is already in the "Generous" mode =)

I'm using Windows 7 x64 and both openPDC and PMU Connection Tester are configured to use IPv4.

 

I have been able to debug openPDC and I got to the code below (TVACodeLibrary\TVA.Communication.ServerBase):

/// <summary>
/// Sends data to all of the connected clients asynchronously.
/// </summary>
/// <param name="data">The buffer that contains the binary data to be sent.</param>
/// <param name="offset">The zero-based position in the <paramref name="data"/> at which to begin sending data.</param>
/// <param name="length">The number of bytes to be sent from <paramref name="data"/> starting at the <paramref name="offset"/>.</param>
/// <returns>Array of <see cref="WaitHandle"/> for the asynchronous operation.</returns>
public virtual WaitHandle[] MulticastAsync(byte[] data, int offset, int length)
{
   List<WaitHandle> handles = new List<WaitHandle>();
   foreach (Guid clientID in ClientIDs)
   {
      handles.Add(SendToAsync(clientID, data, offset, length));
   }

   return handles.ToArray();
}

I noticed that the ClientIDs array has only the value {System.Guid[0]}.

Shouldn't it have the Guid of the PMU Connection Tester?

 

Regards,

Hugo.

Apr 28, 2011 at 9:27 AM

Hello again Hugo,

I still think it is early to jump into the code:

you said your openPDC is configured to use IPv4, did you add the "interface=0.0.0.0" expression? if you did so then please try the following:

1. remove the "interface=0.0.0.0" expression from TCP channel and UDP channel settings on openPDC's "Manage Output Streams" Window.

2. go to PMU connection tester, insert appropriate settings, e.g. C73, openPDC output device channel ID etc. then in the settings tab set "Force IPv4"

to false,  in the configure alternate command channel on the main tab for the host, insert ::1 and the command channel port (e.g 8900 if that is what you set in the openPDC).

next choose the UDP port tab on the main window and insert the the port number as you configured it on the openPDC system in the local port box (e.g. 8800).

if your openPDC is running and connected to your devices and they are streaming this should work on x64 Windows 2008 systems.

 

please check this and configuration is good, also check out the Run time Status and Statisitics tab under the Monitoring option in openPDC Manager,

drill down and expand the "Output Streams" item and check that your system is publishing the measurements etc.

Best and Good luck,

 

Moustafa

 

 

Apr 28, 2011 at 1:09 PM

Hi Moustafa,

Thank you very much for the help.

In fact, it did work when I set "Force IPv4" to false.

But why it won't work when using IPv4? Any ideas?

 

Best regards,

Hugo.

Apr 29, 2011 at 9:09 PM

The openPDC sample data is configured to load with the default IP stack, so on Windows 7 / 2008 this means the stream loads as an IPv6 stream.

You can force this to be IPv4 by going into the Adapters / Concentrator Output Streams in the openPDC Manager and adding ;interface=0.0.0.0 to the TCP Channel and UDP Channel connection strings.

Technically the interface setting allows you to stream data across any specific network card on your system (in case you have serveral), by specifying all zeros in the IP (e.g., 0.0.0.0) you simply request that the system choose the default card.

Using an IPv4 style address (e.g., 0.0.0.0) causes the system to assume you want an IPv4 style socket, using an IPv6 style address (e.g., ::0) causes the system to assume you want an IPv6 style socket.

Hope that helps.

Thanks!
Ritchie