- The
Device ID Codedoes look correct, based on your screenshot. However, I am a little confused why you brought up the openPDC here. Are you able to receive the device configuration in openPDC despite not being able to do so in PMU Connection Tester? - The first error message suggests that the device is proactively closing the connection, probably after an erroneous message was transferred or an extended idle period triggered a timeout. The second error message could indicate that a firewall is blocking the port, but that seems pretty unlikely based on several of your other observations.
- PMU Connection Tester should support all three modes of communication that you’ve listed. That is to say,
TCP,UDP-T, andUDP-Uare all supported.
From the perspective of the network layer, there is no reasonable explanation why the device would ignore one command and respond to another. All commands are sent over the same command channel, and responses are returned over the same channel except in the case of UDP-U. With that in mind, perhaps the issue has nothing to do with the network layer at all.
Upon reviewing your initial error message, I notice that you’ve selected IEEE C37.118.2-2011 and that the device is sending SendConfigurationFrame3. It occurs to me that perhaps the device does not support the SendConfigurationFrame3 command. Have you tried changing the protocol to IEEE C37.118-2005 and/or manually sending the SendConfigurationFrame2 command?