PM8240 Modbus Issue

[Windsor]

I have a system with several PM8240 power meters as serial Modbus slaves to an Easergy T300 RTU. Occasionally the T300 loses communications to the power meters (not all at the same time).

An extract from the T300 Modbus channel trace is shown below:

TX MDBM1Chan 18:14:58.884
02 03 09 5f 00 02 f7 b6
RX MDBM1Chan 18:14:58.905
02 83 02 30 f1

In this example the T300 is requesting a read of the 2 registers that indicate the state of the local plant digital inputs of the meter. The reply message from the meter has the top bit of the function code set (0x83) to indicate an error and the next byte specifies an exception code of 2.

According to the PM8000 user guide a Modbus exception code indicates "Invalid Address" an is descried as:

This code indicates one of the following:
• The requested address is invalid for that function.
• The requested address is not within the valid register
range for this device.
• The requested address is protected by device
security

Can anyone advise as to what the issue could be since Modbus queries to read these registers only fail occasionally.

Note: The same behaviour has been seen when reading analogue values as well.

Thanks in advance.

[Charles_Murison]

Hello @Windsor ,

What version of firmware do you have for the PM8000?  If not V3.1.0, I recommend starting with upgrading the firmware. 

Regards,

Charles

[Windsor]

Hi @Charles_Murison. I'll see if I can find out. Do you know when V3.1.0 was released? The power meters my customer has were installed on site sometime in 2019- 2020 I think.

[Charles_Murison]

Hello @Windsor , V3.1.0 firmware was released November 12, 2021.

Regards,

Charles

[Windsor]

Hi @Charles_Murison, do you know if the latest firmware fixes any Modbus issues?

[Charles_Murison]

Hello, @Windsor , yes the latest firmware version does fix an issue with modbus where any N/A result in a response would instead send modbus exception.

Regards,

Charles

[Windsor]

Could you explain what you mean by a "N/A result in a response"?

[Windsor]

Hi @Charles_Murison,

Could you explain what you mean by "any N/A result in a response " please?

[Charles_Murison]

Hello @Windsor ,

I can use an example. Inside the meter there are multiple Power factor registers, Power Factor signed, Power factor leading and power factor lagging. A system cannot be both lead and lagging, so when system is leading, the register for PF Leading is a value, and PF lagging is "N/A". If system is lagging, PF leading is "N/A" and PF lagging is a value.

"N/A" is abbreviation for not available. If you were to read a register in Real time with a program like Power monitoring expert or ION Setup you would see the text "N/A". There are many possible reasons for a register to be not available. 

if you were to read a block of 20 modbus addresses and any one of those addresses pointed to an ION Register that was N/A, the modbus response from the meter would be modbus exception 2. This only applies to meters with V3.0.0 firmware. V3.1.0 corrected this behavior. 

Regards,

Charles

[Windsor]

Hi @Charles_Murison,

Thanks for the detailed explanation. In my case, the Modbus traces I have captured show the exception code being returned when reading the 2 registers (2400, 2401) that hold "Digital Input Status Validity - Base Unit" or when reading the 6 registers (3000-3005) that hold the phase A,B and C current values. Are there any situations where these registers would be N/A?

Are you aware of any Modbus issues fixed in earlier firmware releases? I haven't managed to find out the firmware in the customer's meters yet.

[Charles_Murison · Accepted solution]

Hello @Windsor ,

Likely this level of troubleshooting would be better done through a technical support case. There are modules inside the ION meter template that map ION register to modbus addresses. Most of this is done through Data mapping modules. Different modules map different groups of registers. Likely tech support would want to see the states of the ION registers at the time of modbus not communicating.

Regards,

Charles

[Windsor]

Hi @Charles_Murison , whatever the problem was upgrading the firmware to version 4.0 seems to have fixed it (meters were running either 3.0.0 or 2.2.1