Greetings!
I’m currently setting up a microPMU on OpenPDC. I started with the PMU Connection Tester Software, which established a connection with the microPMU but was unable to retrieve the configuration frame. After manually sending either configuration frames 2 or 3, the Connection Tester successfully retrieved data and displayed it accordingly…
I therefore continued, trying to set up OpenPDC, using both the manufacturer’s info, manually entered data and the PMU Connection Tester’s file, all of which gave me the error:
"ERROR: Received configuration error frame.
Attempting IEEE C37.118.2-2011 TCP based connection…
Connected to remote device, requesting configuration frame…
Sent device command “SendConfigurationFrame3”…
WARNING: Timed-out waiting to retrieve remote device configuration.
Failed to retrieve remote device configuration."
when requesting a configuration file. I therefore tried both manually entering the configuration and using the PMU Connection Tester’s configuration file, both of which resulted in no data received in the software as shown in the “Monitor Device Outputs” tab.
Despite not getting any data in the OpenPDC software, Wireshark shows packets being sent between the computer and the microPMU, so I’m confused as to why the softwares seem to have so much trouble with them. I have tried disabling the firewall on the microPMU, with no improvement, and to open an exception on the Windows firewall for the OpenPDC executable, neither of which solved the issue.
I have therefore turned to this forum kindly asking for some help with this issue.
On the PMU Connection Tester, there are some control parameters to adjust the automatic retrieval of the config frame, one of them is the SkipDisableRealTimeData setting. My working theory is that the device is not responding to the sequence of “disable real-time data” and “wait a moment for data to stop” followed by request for “config frame 2”. Let us try setting the SkipDisableRealTimeData property to tue and seeing if the automated connection cycle improves. You can find this setting in the PMU Connection Tester under the Settings tab in the Connection Settings section.
If so, we can use this same setting in the openPDC when setting up the device.
If this does not, we can use a serialized XML-based configuration, produced by the PMU Connection Tester, to property setup your device in the openPDC without automatically retrieving the config frame.
Thanks,
Ritchie
Thank you for the prompt reply! As soon as I I get the chance I’ll try your suggestion and give back some feedback!
Hello again!
So I’ve tinkered with the mPMU some more, with no advances. Your suggestion has, unfortunately not yielded different results. The device’s manual actually states that the SkipDisableRealTimeData setting should be set to True.
In the meantime I found out newer versions use the UDP protocol for C37 communication, instead of TCP as in previous versions. I have not, however, had much success in setting it up, with the PMU Connection Tester receiving no response, and seemingly not sending any commands. This could, however, be my fault for not setting it up correctly.
Further analyzing the OpenPDC’s behaviour, i noted that there’s no shortage of packets beeing sent between the mPMU and the computer, and that in the software’s log the connection is correctly set up, but OpenPDC does not receive data, so it drops the connection and retries.
You mentioned the usage of a serialized XML configuration, could you please elaborate on it? Is it the PMU connection Tester’s files based setup?
Ah, UDP. Many potential pitfalls here…
- I would recommend going with a pure TCP connection for simplicity in testing - check the microPMU configuration.
- If this is not possible, make sure the configuration of the UDP destination IP and port in the microPMU are set the machine running the openPDC
- You may need to update Windows firewall for the PMU Connection Tester / openPDC to allow an exception for IP traffic - could be that UDP packets are being blocked
- There are several ways to configure reception of UDP, e.g., TCP command channel with a UDP data channel, UDP unicast, UDP multicast, etc. – you will need to make sure PMU Connection Tester is setup to receive the data in fashion configured in the microPMU
- UDP is an unreliable transport - there are no guarantees you will receive your configuration if any one of its fragments is dropped during transmission - see suggestion #1 above
Thanks,
Ritchie
Hello!
I have been using TCP the whole time, only tried UDP a couple hours ago.
I that case, here are the steps to use serialized configuration frame:
- Open PMU Connection Tester, connect to device as usual
- Make note the Device ID Code used to connect to device
- Once connected and receiving data, click on “File > Config File > Save” from the menu
- Save the XML config file to the openPDC install folder, e.g.,
C:\Program Files\openPDC\microPMU.xml
a) Note: this may require elevated Windows privileges, may need to save to Desktop and move file to target folder
- Open the “openPDC Manager” application (UI version, not web page)
- Click on the “Input Device Wizard” button from the home page
- Enter normal connection information in the “Connection String” area
- Add
; configurationFile=microPMU.xml to the end of the connection string using whatever configuration file name you chose (note that the semi-colon is important)
a) You do not need to use a path for configuration file here when file is saved into the openPDC install folder
- Enter “Device ID Code” noted in step 2
- Click “Next”, then from the line labeled “Configuration File”, select the folder icon at the end of the text box and browse to serialized config file, e.g.,
C:\Program Files\openPDC\microPMU.xml
- Click “Next” and “Finish”
Hello again!
I tried your suggestion, twice. I’m afraid to report the outcome is no different. I am at a loss, Wireshark shows packets being sent and netstat an open TCP connection.
Do you have any more ideas?
In PMU Connection Tester, is the device ID code for the PMU itself different from the ID code from the connection?
The connection device ID code is under the “Protocol” tab, once connected and receiving data, the PMU ID code is listed on the “Configuration Frame” tab.
If they are different, edit device configuration in the openPDC and use the PMU ID code instead.
Thanks,
Ritchie
I am sorry to inform it is the same.
I shall try a different computer, maybe the firewall is acting up.
Will get back later.
Thank you a lot for your time, Tiago
Hello again!
I have tried another computer, with a completely disabled firewall and the outcome was the same.
I’m starting to suspect the mPMU is at fault here, as the PMU Connection Tester only works when I manually send the configuration frame.
I am going to look for more help, this time with the manufacturer.
Thank you a lot for your availability and help.
Best regards, Tiago
