We keep getting the error “No connection can be made because target machine actively refused it” when we try to use PMU Connection Tester to connect to one of our SEL-421 boxes. Based on another thread, we see possible errors being the IP address, Port #, or the Device ID. We are confident we have the right IP address and have IPV4 set to TRUE. We have tried standard ports 23 (telnet), 4712, and 4715 without luck. We are not sure if the Device ID matters. We have tried 235 (legacy), 0, 1, and 2, all without luck. We are able to connect to the box using SEL’s acSELerator QuickSet program. We do not see anywhere in acSELerator what might be required for the Port or Device ID. We do not currently have an external clock driving the SEL-421 but are not sure if this matters for PMU Connection Tester. We also do not have the IP address for our network switch (we inherited it) but it does not seem to matter for acSELerator. Please provide any guidance for setting the Port or Device ID or what else could be causing the error. Thanks in advance!
Can you ping the device (assuming the SEL device supports a ping)…
May be a routing issue - is the SEL on the same network within the same subnet?
Still sounds like a configuration issue of some kind…
Hi Ritchie, Yes, we are able to ping the device and it has to be on the same subnet in order to actively refuse connection so I agree that it must be a setting of either the Port number or the Device ID. Do you have any guidance on what should be used in those parameter fields? Is there any enabling signal that we might be missing? The handbook mentions one such setting but we do not see it anywhere in acSELerator or in the front panel display.
I was able to find an old version of the reference manual for the SEL-421 that suggests you may need to connect to the device over a serial connection to get synchrophasor data. I don’t have access to the latest documentation to be able to say whether there is a configuration that enables synchrophasors over TCP/IP, but maybe you can’t find the setting because the SEL-421 does not support it.
Hi Stephen, I think we have determined the issue. It looks like we are not sending a high-resolution clock signal to IRIG. It looks like without this signal, it presumes no valid synchrophasor data and refuses the connection.We do have an SEL-2407 GPS clock but do not yet have the antenna. We will look into whether we can make it look like a hi-res clock and test our theory.
Hi Stephen, we connected a hi-res clock, but we found a more subtle setting that was required in PMU Connection Tester. Specifically on the TCP tab, we needed to click on “Configure Alternate Command Channel” and check the box that says “not defined”…then we were able to make the connection and see the synchrophasor data. Apparently it must have been looking for another network path.
The alternate command channel setting can be used to define a separate communications path for frames that are not data frames. That is to say, command frames and configuration frames get transmitted over the command channel and data frames are transmitted over the data channel. While it is possible to define several different combinations of communications paths, the most common configuration is to define a TCP command channel and a UDP data channel. If you had an alternate command channel defined, the PMU Connection Tester would have attempted to connect to the command channel before attempting to connect to the data channel, which does explain the issue you were having.
I was having the same problem due to not configuring an alternate command channel and not checking the “not defined” box. It was resolved by checking the “not defined” box.
However, I also got the connection actively refused message with the NW cable unplugged meaning there was no way to reach the target, and the target could not have actively refused the connection.
The following application changes would be helpful:
- By default have “not defined” box checked.
- If there is no path to the target do not display the connection actively refused by target message.
Thanks for the feedback. While I don’t think we will be able to make the changes you requested, I hope these explanations will be satisfactory.
- Certainly, changing the alternate command channel setting would be helpful for new users that are only trying to connect to PMUs that do not have an alternate command channel. However, that only represents part of our user base, and there are also good reasons not to change it as well. Note that the default settings we selected for the PMU Connection Tester are designed to connect to the openPDC sample data set so that both of these products can communicate with each other out-of-the-box. Also, if you change the settings in the PMU Connection Tester, it should save the settings you selected the last time you exited. Then, the next time you run the application, it will attempt to find those saved settings and restore them. Therefore, a change to the defaults would only really be relevant to users who are using the application for the first time.
- When using the PMU Connection Tester to connect to another system, I get this message when my laptop is in airplane mode:
A socket operation was attempted to an unreachable host. Based on the fact that you didn’t receive that message, I would speculate that there’s a chance that there actually was some network path on your computer, such as through a Wi-Fi network or a virtual network adapter, that could be used to reach a computer that refused the connection, even with the network cable unplugged. At any rate, these error messages displayed by the PMU Connection Tester are derived using the .NET Framework based on an error code that is provided by the operating system. We don’t pick the messages, and there’s no way for our application to determine whether the operating system is telling the truth when it comes to whether the connection is refused versus whether the host is unreachable.
Thank you for your response. With Regard to the connection refused message, I suspect that since the alternate command channel by default uses the loop back interface, and I did not have openPDC, my own PC was actively refusing the connection.
Also, I agree that I did not have the expected default alternate command settings since I was not using openPDC.