Communication Issue with ION9000 Series Power Quality Analyzers

[DEMIR]

Hello; 

We currently have approximately 70 ION power quality analyzers deployed across our facility. ION7650 models have been in operation since 2014, while the ION9000 models were introduced into the system at the beginning of this year. The monitoring software in use is Power Monitoring Expert (PME) version 2024.

The site network topology is based on three independent fiber optic rings. All analyzers communicate with the central PME server via Ethernet connections through managed switches installed on these rings.

The issue we are experiencing concerns the ION9000 units. After operating for a certain period, these devices intermittently lose Ethernet connectivity. The only way to restore communication is by power-cycling the affected analyzer. This disconnection and reconnection cycle repeats at irregular intervals.

It is important to note that we have not encountered this behavior with the ION7650 analyzers, which are operating on the same network infrastructure. Furthermore, other Ethernet-based field devices—such as RTUs, protective relays, and gateways—are functioning without any communication issues.

There are no IP conflicts, and a detailed review of the ring structure and switch configurations has not revealed any abnormalities. At this point, we are unable to identify the root cause of the problem.

Could you please advise if there is a known issue related to Ethernet communication stability on ION9000 devices, or if there are any recommended firmware updates, configurations, or diagnostic steps we should follow?

Your technical assistance on this matter would be greatly appreciated.

Best regards,

[Mehran_Mehrnia]

Hi @DEMIR 

If the local network topology is a ring or loop Ethernet configuration, the ION9000 supports Rapid Spanning Tree Protocol (RSTP), provided that RSTP is enabled in the meter's Ethernet communication settings

(ION Setup -> Setup Assistant -> Communications -> Advanced Ethernet -> Protocols -> RSTP).

If meters are running older firmware versions (e.g., earlier than V3.0), it is recommended upgrading to the latest versions (The current release is V4.6) which include improvements to the meter’s functionality, as well as RSTP enhancements in longer Ethernet loop configurations.

ION9000 user guide: Ethernet loop topology

Best Regards

-Mehran

L3 Expert Advanced metering

[Charles_Murison · Accepted solution]

Hello @DEMIR 
Are the switches connected to the ION9000 meters able to filter network traffic not intended for the ION9000 (broadcast messages for example)? The ION9000 meters have methods the protect the metering functionality if too much network traffic is seen.

Also are the switches using any kind of 802.1x authentication or MAC address bypass. Some limitations on what the ION9000 can support?

If meters not communicating over network, if you connect to the second Ethernet port locally on the meter is the meter able to communicate? 

Regards,

Charles

[DEMIR]

Hi @Mehran_Mehrnia ,

Thank you for your response. Regarding the local Ethernet topology, there is no ring or loop configuration; all Ethernet cables are connected directly to the switches.

In terms of firmware versions, we previously had V2.2, V3.1, and V4.0 deployed. As of yesterday, we have upgraded all analyzers to version V4.6.

Hi @Charles_Murison ,

The issue of network traffic and filtering had been considered. To investigate this further, we reviewed the switch configurations, including fiber ring RSTP, BPDU Guard, and PortFast settings. As an alternative, we are also considering creating separate VLANs to isolate the analyzers from the rest of the network.

The scenario you described — “The ION9000 meters have methods to protect the metering functionality if too much network traffic is seen.” currently appears to be the most plausible explanation.
Is there a way to verify this through the ION9000 logs? If so, could you please advise on how we can access and interpret these logs?

Please note that 802.1x authentication is not enabled in our network.

There is still one analyzer in the field experiencing communication issues that we have not yet reset. I plan to test connectivity via the second Ethernet port and will provide an update accordingly.

Thank you very much for your continued assistance.

[Charles_Murison]

Hello @DEMIR ,

The status specific to throttling requires the help of Tech support to access specific commands. Each meter would need the help of tech support. I would suggest setting up the VLANs as a good practice .

Regards,

Charles

[DEMIR]

Hello Everyone;

Today, we carried out on-site communication tests on the power quality analyzers. The current situation is as follows:

We connected a laptop to the second Ethernet port of an analyzer that was experiencing communication issues. While we were able to successfully ping other analyzers within the same network, we could not ping the analyzer’s own IP address.

We then repeated the same test via the first Ethernet port, but the result remained the same — the analyzer did not respond to ping requests directed to its own IP, although communication with other network devices was functional.

As the next step, we performed a power cycle on the analyzer (disconnecting and restoring its power). After rebooting, we retried the communication tests and observed that the analyzer responded to ping requests successfully.

Following this, all analyzers in the system were upgraded to firmware version v4.6. We will continue to monitor the analyzers for a period of time. In case the issue reoccurs, we will migrate the analyzers to a different VLAN to further isolate and monitor the situation.