CAT EMCP Modbus Confirmation

[bigLee]

Hello,

I am trying to verify the following info from a CAT modbus map. I'm having issues getting meaningful data from these:

Total Fuel Consumption 40254 ?
Watts Real Total 40407 F -2,000,000,000 to +2,211,081,215
Coolant Temp 40201 -273 to 1735
Fuel Consumption Hrly 40256 0 to 3212.75

I cant find 40407 in any mapping. The scale ranges seem to be off as well. Any info from someone experienced in this is much appreciated!!

 

[drbitboy]

Hello,

I am trying to verify the following info from a CAT modbus map. I'm having issues getting meaningful data from these:

Total Fuel Consumption 40254 ?
Watts Real Total 40407 F -2,000,000,000 to +2,211,081,215
Coolant Temp 40201 -273 to 1735
Fuel Consumption Hrly 40256 0 to 3212.75

I cant find 40407 in any mapping. The scale ranges seem to be off as well. Any info from someone experienced in this is much appreciated!!

1) Are you getting values from the Modbus server (a.k.a. "slave")?

1.1) If yes, what values are you seeing (hexadecimal preferred), and what values do you expect to see (e.g. "I am getting 3.219e-38 and I was expecting 3198.7")?

2) What devices are the Modbus participants (PLC? Catepillar excavator? Instrument? PC? etc.)?

3) Do you know the relationship between protocol addressing (0-65535) and Modbus data model addressing (1-65536), and the interpretation of same by the Modbus client/master, the Modbus server/slave, and any interfaces used to set up the communication? The answer will be one of three possibilities:

• yes: good for you
• no: go look it up
• I don't understand the question: tighten your seatbelt, Hoss

4) Can you provide a link to the user manual that has the Modbus map?

Dr. Bitboy, D.M.D.
-

 

[jschulze]

If the following guide applies to your equipment, I'm not surprised the data doesn't look meaningful due to the crazy scaling and offsets this thing apparently uses (register list at the very end).
https://www.ccontrols.com/support/dp/ManualEMCP4.pdf


For example, register 202 (Engine Coolant Temperature) has the following for the Data Interpretation column:
Scaling: 0.03125 C/bit, Offset: -273 C,
Data range: -273 to 1735 C

Assuming this follows a standard y = mx + b scaling equation, y would be the temperature, x would be the raw Modbus register value, m = 0.03125 and b = -273. Therefore, for a temperature of 50C the raw Modbus value would be 10,336.

 

[drbitboy]

If the following guide applies to your equipment, I'm not surprised the data doesn't look meaningful due to the crazy scaling and offsets this thing apparently uses (register list at the very end).
https://www.ccontrols.com/support/dp/ManualEMCP4.pdf

Ooh, nice find! That is actually pretty well laid out, especially Appendix A cf. here, as @jschulze notes.

So the behavior of the CAT ECMP Modbus server/slave appears to be well-defined. That means all of your trouble will be on the client/master end. What kind (manufacturer, model, firmware rev, etc.) of a client/master device are you using?

The trouble spots I would expect to see are

• • 16-bit words
    • Modbus, and especially holding registers, are all about the words, which are 16-bit unsigned integers with a range of [0:65535]
      • That EMCP4 manual makes an explicit statement (on page 15) that the Modbus data are unsigned
    • But it may be that your client that receives those words is interpreting them as 16-bit signed integers with a range of [-32768:+32768]
  • 32-bit words
    • Modbus does not have a data type other than 16-bit words
    • so 32-bit words are sent as two adjacent (contiguous, sequential) 16-bit words.
    • Combining the 16-bit words received on your client device will be specific to that device's architecture, coding environment, available data types, etc.
  • Other lengths of data entities e.g. 3 words for Real Time Clock data
  • Addressing: Modbus Data Model vs. PDU (Protocol Data Unit)
    • First of all, the only data available on this ECMP 4 device are Holding Registers; Holding Registers are one of four Primary Tables in the Modbus Data Model.
      • Sidebar/Caveat:
        • For most clients of ECMP 4 servers, this means the Modbus address to be read will range from decimal 40001 to 49999, although some will use, again decimal, 400001 to 465536
        • BUT that adjective "decimal" that I used there can be misleading, because of the leading 4, highlighted in the addresses above.
        • Specifically, that leading 4, in the context of Modbus Data Model addressing, is best not thought of as a part of the decimal value of an actual address;
        • That leading 4 is instead a prefix that by general convention tells us that the rest of the address that follows is the ordinal number of a block of data called Holding Registers in the Modbus Data Model.
        • For example, another block of data in the Modbus Data Model comprises Input Registers, which have a prefix of 3, i.e. 30001 to 39999 or (300001 to 365536), again by general convention.
        • And as if it isn't confusing enough, the Modbus Function Code 03 (0x03) is used to read Holding Registers (i.e. those with prefix 4), and the Modbus Function Code 04 (0x04) is used to read Input Registers (i.e. those with prefix 3).
        • So be aware of what you are implying when you use terms like 40407.
        • End sidebar, but the key takeaway is that
          • A leading 4 prefix ≡ Holding Register
    • Modbus Data Model addressing for the ECMP 4
      • As noted above, all ECMP 4 Data Model addressing will be for Holding Registers
      • So by general convention, the range will be 40001 to 49999
      • However, since there are only Holding Registers, the manual's Appendix A (page 49) drops the leading prefix and only lists the ordinal decimal number of each Data Model Holding Register, 100 through 2259 (decimal; non-contiguous).
    • Modbus PDU addressing for the ECMP 4
      • PDU addressing can refer to the same elements (registers) of the same Primary Tables of the Modbus Data model.
      • However, the way the PDU refers to the table is by way of the Function Code used in the protocol i.e. in the data "on the wire."
      • However, and again by convention, PDU addressing refers to the offset of each element (register) from the first.
      • PDU addresses are often expressed, as they are in the ECMP 4 manual, in hexadecimal e.g. 0x0000 or 0x0063, that is only a general convention
      • So PDU address 0 (decimal; 0x0000 hexadecimal) using Function Code 03 (0x03; Read Holding Registers) refers to Holding Register 1 (40001) of the Modbus Data Model.
      • Note that PDU addressing is always what is used on the wire i.e. in a Modbus TCP packet or in a Modbus RTU serial stream, so if you can sniff those data it is fairly easy to deduce how the sending entity interpreted its input data.
    • Example
      • E.g. in Appendix A, the first (holding) , Generator Average Line-Line AC RMS Voltage, is listed as 100 (decimal, i.e. the 100th register) for the Modbus Data Model address, and as 0x0063 (hexadecimal, = 99 decimal) for the PDU address.
    • On the client
      • So the question is, when configuring the client that you have to read a register from the ECMP 4, how does one specify the address?
      • This is a non-trivial question, because each client's manufacturer has written their user interface to take a different path to the goal e.g.
        • Use the prefix+ordinal convention, so specify 40100 to get the 100th Holding Register
        • Specify Primary Table and ordinal of the register in that table, so "Holding Register" and 100 (decimal) to get the 100th Holding Register
        • Specify Function Code and PDU address, so Function Code 03 (or 0x03) and either 99 decimal or 0x0063 hexadecimal to get the 100th Holding Register
        • Or any combination of those.
      • There are several threads in this forum where someone was getting unexpected data via Modbus because they were off by 1 i.e. they were specifying the Modbus address but their client was interpreting it as a PDU address, or vice versa.
      • The best debugging tool we have is to assume that
        • A) all of the pieces of the system, client, server, and everything in between, are interpreting all requests and inputs and executing all actions exactly how they were programmed to do, and
        • B) Nary one of those pieces cares a whit what we want them to do or what we think we told them to do.

 

[BobB]

That format is J1939 - yes - get used to doing floating point maths! Been there - done that!

Also having to go 1 to the left is common, then there is big and little endian and a few other things as well.

 

[Saffa]

Have you ever played a game that you don't want to play any more

Although its spam, this is highly relevant to figuring out random equipment Modbus maps.

I came across one which had been left for dead for 3... three! .. years. After a few calls to the OEM and old emails from the client, turns out the OEMs local agent sent the site the wrong mapping file. After getting right addresses.. boom... all working in an hour.

To the OP... Dr Bitboy loves a bit of byte swapping, so if you come back with the numbers he'll figure it out. The guy is a rocket scientist, literally.

 

[bigLee]

That is the correct EMCP manual mapping I am using. My application is a Digi-Key modbus/Enet gateway polling to a wonderware SCADA HMI.

Here's an example of how I get some working and not these.

40202 right manifold exhaust temp. Raw modbus value 30(30 celsius). My scaling for this raw value in HMI software is raw: 0-64255, EU: -273 - 1735. I get a correct value after Fahrenheit conversion of 86. All my data points with the 64255 scaling track accurately.

Just seems like deviations from this are giving me problems.

 

[drbitboy]

40202 right manifold exhaust temp. Raw modbus value 30(30 celsius). My scaling for this raw value in HMI software is raw: 0-64255, EU: -273 - 1735. I get a correct value after Fahrenheit conversion of 86. All my data points with the 64255 scaling track accurately.

Hmm, I am a confused:

First, is that (40)202 or (40)242? 202 is battery voltage.

Second, per the formulae provided in that manual (i.e Page 37):

MEASURED_DATA=(RAW_DATA×RESOLUTION)+OFFSET
​

RAW_DATA=(MEASURED_DATA-OFFSET)/RESOLUTION
​

for a manifold temperature of 86°F (30C), with RESOLUTION=0.03125 and OFFSET=-273 (Page 53), I would expect a raw Modbus unsigned 16-bit integer of 9696 = (30C - -273) / 0.03125). Then the conversion to MEASURED_DATA would be

(0.03125 * 9696) - 273 => 30C => 86°F

​

A RAW_DATA value of 30 converts to around -272C or 1 Kelvin, so not very realistic.

One possibility I thought of was that the Modbus client is interpreting the bytes as swapped in the Modbus word, so a raw value of 30 (0x001e) is actually 7680 (0x1e00), but that converts to -33C = -27.4°F, so that is also not very realistic.

P.S. it's probably 0 to 64256, not to 64255, because 64255/(1735 - -273) = 31.999... and 64256/(1735 - -273) = 32 exactly, so 32 counts per °C.