I’m running some tests on a PMU to connect it to PMU Connection Tester via the different protocols available. It works correctly for TCP and for TCP/UDP combined but I can’t make it work for full UDP. PMU Connection tester apparently receives data (hexadecimal data in “Real-time Frame Detail” is continuously updated) but the data does not show in the graphs. Also when requesting a Config Frame, I can see in Wireshark that the response from the PMU is “destination unreachable”. For information, the firewall is already fully disabled.
The PMU allows to configure a Data Port and a Config Port and the configured values are the following :
Data Port = 4712
Config Port = 4713
PDC Port = 5000
Would you know why the data shows up this way and not in the graphs ? Is it useful to enable Multicast to request the config or not ?
The PMU is telling you it does not have a route back to the IP of your machine. This could be firewall, but if disabled on all pathes between, then it could be the return route from your PMU to your machine causing the issue. For example, is the IP of your Windows computer in the same range as the PMU?
Does your Windows computer have multiple network interface cards (NICs)? Does one of the NICs have a matching IP range for the PMU? If so, try changing the selected “interface” (link from PMU Connection Tester) to the NIC that matches the network configured for the PMU.
The IP of the PC is 192.168.1.2 and the one of the PMU is 192.168.1.17. And the PC only has one RJ45 interface (and a wifi card) and we effectively selected the RJ45 interface.
Thank you.
Julien
“Destination unreachable” is not something you can typically see in Wireshark. It’s an error message that gets returned by the network layer, but isn’t actually sent over the network. I’m curious what it is you’re actually seeing.
It’s interesting you have three ports configured on the PMU. It sounds like the intent is to have a UDP alternate command channel where the data channel is unicast. If you tried to set that up, you may have noticed that there is no UDP option under Configure Alternate Command Channel so it’s not really supported.
Which one of the ports is not standard among the ones I mentioned ? Do you know ?
And, independently from the command that does not work, do you know what can explain the fact that we see the hexadecimal data but no interpretation of it ? Is it just because we don’t receive the config frame ?
Yes, it’s because you don’t receive the config frame. It’s not that any of the ports are non-standard, but that the standard (afaik) doesn’t support separate UDP channels for data and configuration. That command/data channel duality was intended to support TCP+UDP scenarios. If everything is going over UDP, then it’s easiest to have just one listening port on each side of the communications.
Hm, unfortunately the documentation they provide online is not helping. I don’t see any information about the Data Port or Config Port settings that you mentioned, or even how to switch between TCP, TCP/UDP, and full UDP.
All I can really say is that, for full UDP communications, the openPDC only supports a single UDP channel for both configuration and data. This communication mode accepts a single local port on which the openPDC expects to receive both data and configuration, plus a remote endpoint (IP + port) to which commands will be sent. The PMU would typically require the same three configuration options, so there should only be two ports.
It’s possible that the PMU wouldn’t need to know the remote endpoint in advance because it can simply stream data to whatever endpoint it receives commands from. However, I believe this is pretty atypical because most PMUs support one-way UDP data streams where they do not accept commands at all.
