openPDC doesn't receive data

GPA Products openPDC
1

Hello!
I’m Marco Gonzalez and I’m trying to set up openPDC to work with a dummy C37.118.2-2011 PMU for testing purposes (the dummy PMU sends the same data everytime only changing timestamp and crc). The dummy PMU uses an UDP channel for sending data (data frames, config frames and header frames) and a TCP channel for receiving commands.

If I use PMU Connection Tester to test the PMU it works OK.

Pasted image1422×376 24.9 KB

Pasted image1413×766 38.5 KB

In Wireshark I also see that the data frames are OK.

Pasted image773×176 8.42 KB

In openPDCManager I use the same settings to setup the dummy PMU than in PMU Connection Tester (Imported connection and configuration files)
But the openPDC terminal says that it doesn’t receive data.

Pasted image1220×246 9.08 KB

It seems that openPDC doesn’t receive anything through the UDP data channel (Configuration frames + Data frames). I double checked the UDP port configuration and it’s OK.

Do you have any idea why it’s failing?

Thank you and best regards.
Marco.

2

Check the ID code defined in the openPDC manager for the device, in your case based on info above it will need to be set to 12345 - if this does not match it will not be able to map any data for the device.

3

Hi Ritchie.

Thank you for the fast response.
Yes, it was already set to 12345.

Pasted image1802×612 56.7 KB

Does the “Acronym” or “Name” in openPDC Manager need to match the PMU name (STN)?

4

I will eliminate the possibility that the PMU Connection Tester is running while the openPDC is trying to connect since there are no errors to indicate this on the capture of the remote console screen.

We have seen with some devices that the ID of the “frame” does not match the ID of the “PMU” - for direct connect devices, i.e., not part of a concentrator - and this can cause issues.

From the remote console session can you issue the command “LIST PMUTEST” and try to capture as much detail as you can?

Specifically we are looking for ID codes for the connection and the devices as reported by the configuration frame.

Alternately you could just save configuration as an XML from the PMU Connection Tester so we can review…

Thanks,
Ritchie

5

Also - if the ID’s cannot be matched - the system will fall back on trying to match by name. So in this case, changing the device “Acronym” to match the one defined in the Configuration Frame could help.

Another source of confusion is often this: if the connection is to a PDC, and not to a standalone device, the “Connection is to Concentrator” flag should be selected (on Step 2) when adding the device from the Device Wizard screen in the openPDC Manager. Many time selecting this option will resolve many connection issues related to device connections and mapping data…

6

Hi.

list PMUTEST:

Pasted image693×687 20.6 KB

Pasted image835×670 28.3 KB

Pasted image799×443 13.8 KB

Configuration XML:

<div style=font-size:9px;font-family:Arial, Helvetica, sans-serif;width:127px;font-color:#44a854;>

The connection is with a PMU through a gateway which just forward the C37 frames.

Thank you.

7

Nothing wrong with configuration. However, I do not see a command channel defined in the connection string for the device - I would expect something like this:

                Adapter ID: 9
         Connection string: 17 key/value pairs

                Localport = 4713
        Transportprotocol = Udp
           Commandchannel = protocol=Tcp; server=192.168.1.21; port=47000; maxSend...
           IsConcentrator = 0
                 AccessID = 12345

This tells me that the alternate command channel is not being properly established.

Let’s do this, in openPDC Manager go to “System / View Iaon Tree” from the menu. Find your PMUTEST device and hover over it so that the tool-tip shows up. In this tool-tip that displays the connection string tell me if you see commandChannel={protocol=Tcp; server=192.168.1.21; port=4700; maxSendQueueSize=-1; islistener=false; interface=0.0.0.0} somewhere in the string?

If not, we need to go back and edit the device’s alternate command channel and see what’s going on there. Is there an ; interface=0.0.0.0 in the alternate connection string? This forces IPv4. Can you provide a copy of the full alternate command channel connection string text?

Thanks,
Ritchie

8

Also, for reference, what version of the openPDC are you using?

9

Hi.

I’m using the lastest estable one. (v.2.3.40 64 bit)

Sorry, the alternate command channel didn’t appear in the screenshot because i had removed it to test.

The alternate connection string is:
port=4700; maxSendQueueSize=-1; server=192.168.1.21; islistener=false; transportprotocol=tcp; interface=0.0.0.0
And yes, it appears in Iaon.

From the PMU side, I see openPDC sending the command to get the PMU configuration frame, the PMU answers with the frame but it seems that the openPDC doesn’t “see” the configuration frame.

10

Is it possible that another application is already listening on UDP port 4713? Could the Windows firewall be blocking?

You may need to add the openPDC application as a firewall exception.

The system appears to be is sitting around waiting to receive a configuration frame (or any data for that matter).

You can check that no other applications are using the port by issuing a netstat -a -b -p UDP from an administrator command prompt.

You could also simply try using another UDP port.

Thanks,
Ritchie

11

That’s it! It was the Windows firewall :sweat:.
I assumed that Windows asked me the first time, but no…
I have just manually added the openPDC and now it works!

Thank you Ritchie. :smiley: