PM8ECC periodically resets using Ethernet SNMP communication

Issue
The PM8ECC resets and communication is lost via the SNMP with the meter for a period of time.

Product line
PM8ECC

Cause
Communication to the PM8ECC fails at times when trying to performing get-requests to retrieve data. Using SNMP to poll the PM8ECC MIB on a periodic basis causes the ECC to reset due to underlying OS limitations.

Resolution
Registers 1635 and 1636 are a 32-bit word value that defines at which count the PM8ECC will reset after being polled via SNMP.  The default value is 2,000,000.  If the user finds that the PM8ECC gets hung up (no longer responds to SNMP polls) this value can be changed to a smaller value.  To do this, the user should follow the following steps:
1. Write 9020 to PM8ECC (slave id 254) register 2800
2. Write 9022 to PM8ECC register 2800
3. Write the desired value to registers 1635 and 1636
4. Write 1 to register 2801
5. Write 9021 to register 2800
6. Write 1110 to register 2800.
The default value of 2,000,000 was derived from testing.  If customers are finding that their PM8ECC is "locking up" and not resetting, this value can be changed.

• If the customer has SNMP traps set up, they will receive trap messages from the ECC notifying the SNMP manager that the device has powered up.
• Diagnostic counters get reset when the device resets. So, if the customer needs these values for any reason, they need to be aware that they will reset to 0.
• All communication will be lost during this reset period. Therefore, you don't want to make this value too small, as the device resetting frequently will cause other unforeseeable issues

• Example 1:   Customer reported that SNMP trap packets ceased to send from the PM850s after 11-12 days after which time the "Monitoring" tab on the PM8ECC web interface will be greyed out.   This behavior could be reset by accessing the "Setup" tab on the PM8ECC cards web interface.
• Example 2: All the SNMP communications from the PM8ECC responses from the device in response to SNMP get-requests.  These requests occurred every minute and as initiated by StruxureWare Central software.  This same problem was been replicated in a lab by sending get-requests from a Linux based operating system.  Responses from the PM8 would drop out periodically and then completely stop at ~3 weeks of normal operations at a polling rate of about once per minute.  The incidence rate of the problem could be accelerated by increasing the polling rate.