How do I decode M307 Temperature Guard data in Ignition?

The Quick Client shows Good because Ignition's generic TCP driver reports a healthy connection. It does not decode the payload. The M307 returns a 60-byte binary status record. Every temperature, humidity, alarm, resolution, and unit field sits at a fixed byte offset inside that record, and the generic driver has no map of those offsets. To get usable values, send the documented status-read command from a script, receive exactly 60 bytes, decode the record, and write the results to tags.

Why does the Quick Client show only "Good" for the M307?

A status read passes through these points:

1. The Ignition gateway opens a TCP client socket.
2. The request crosses the plant Ethernet to the M307 listening port. The reference reader uses 10001.
3. The M307 answers with a 60-byte record.
4. The generic TCP driver frames those bytes into a message tag.
5. The OPC server publishes that tag to the Quick Client.

Useful data stops at step 4. The driver treats the payload as a message string, and the record is binary. It starts with 0x3F 0xCD 0xDC 0x00, holds signed 16-bit big-endian values, and uses bytes such as 0x00 and values above that do not render as text. The Quick Client therefore shows the tag quality (Good) next to a value that is empty or unreadable.

The M307 read is also a request/response exchange. The client must send the status-read command each time it wants a fresh record:

• Bytes 1-4: 0x3F 0xCD 0xDC 0x00
• Bytes 5-60: 56 bytes of 0x00

A driver that only frames incoming bytes cannot issue that command on a schedule. It also cannot turn the reply into engineering units. For those two reasons, change the approach instead of tuning the driver.

What is inside the 60-byte status record?

Table 1 of the SDK integration guide (SDK-M307-M308-M309, revision 1-7) is the authoritative map. The layout the decoder relies on is below. Byte numbers are 1-based as the guide writes them; indices are 0-based as code uses them.

The device reports sensor faults as reserved raw values in the measurement field:

Signed conversion follows the Java example in section 1.3 of the SDK guide:

1. Mask each byte with 0xFF.
2. Compute value = (MSB << 8) | LSB.
3. If value >= 0x8000, subtract 0x10000.

Worked example: gives 65336, which becomes -200 after the subtraction. At 0.1-degree resolution that is -20.0.

One ambiguity needs a decision. The reference reader compares the sentinels against the raw integer before scaling. At 0.1-degree resolution, a raw 999 could otherwise read as a legitimate 99.9 degrees. Check the SDK guide to confirm that sentinels are raw counts in both resolution modes before relying on that ordering.

Which integration path fits: TCP driver, gateway script, external script, or custom module?

Four paths can move this data. They differ on whether they can send the command, decode binary fields, and land values in Ignition tags.

Recommendation: use the gateway timer script, and prove it first with the standalone reader.

• Ignition scripting runs Jython 2.7. The reference reader targets Python 2.7, not 3.x, so its decoding logic moves into the gateway almost unchanged.
• The custom module is the cleaner long-term architecture. It is a Java project against the Ignition SDK and costs far more to build and maintain.
• A working script that already decodes the record is the best specification for that module, so it is not wasted effort if you build the module later.

How do I prove the network path to the M307 before writing gateway code?

Check the path bottom-up. A script failure on a dead link looks the same as a decoding bug.

1. Confirm link and addressing. Ping the M307 from the Ignition gateway host itself, not from an engineering laptop on a different VLAN.
2. Confirm the TCP port is open from the gateway host:
   • Windows:
   • Linux:
   If the connection is refused, read the listening port from the SDK guide or the unit's network settings. 10001 is the reference reader's default, not a guaranteed device setting.
3. Disable or delete the generic TCP driver device in the Ignition gateway configuration. Embedded TCP servers commonly service a limited number of client sessions. A driver holding the socket can cause refused or stalled script connections.
4. Run the standalone reader with Python 2.7 from a host on the same network: python read_status_record.py 192.168.1.100 10001, replacing the example IP. A good read prints parsed JSON. A ValueError on record size or command bytes points to framing, not decoding.

How do I poll and decode the record in an Ignition gateway script?

1. Create memory tags under a folder, for example [default]M307/. For each of Temp1, Temp2, and Internal, add Value (Float), Status (String), TimeOut (Integer), and OutOfLimits (Boolean). Add Humidity/Value, Humidity/Status, Unit, and CommOK. These paths are examples; keep them consistent with the script.
2. Put the functions in a project library script named m307. Library scope avoids the variable-scoping surprises that functions defined inside event scripts can hit.
3. Set that project as the gateway scripting project. Add a Gateway Timer Event that calls m307.poll().
4. Set the timer to fixed-delay mode. Make the period longer than the 5 s socket timeout so an unreachable unit cannot stack overlapping executions.

Design choices in the script:

• One connection per poll. Opening and closing the socket each cycle keeps every read aligned to a fresh request. A leftover partial record from a previous cycle cannot shift the offsets.
• Byte masking. The & 0xFF masks mirror the SDK's Java example. In Jython, bytearray elements are already 0-255, so the masks are harmless there. They matter if you port the logic to Java for a custom module, because Java bytes are signed.
• Unmapped bytes. Fields in bytes 25-58 are not decoded. Add them from Table 1 using the same s16/u16 helpers.

What do bad M307 reads look like, and what causes them?

How do I verify the decoded values against the M307 itself?

1. Compare each Value tag against the M307's own local reading at the same moment. Check sign, decimal position, and unit.
2. Warm or cool one probe. Confirm that only its tag moves and that the change appears within one poll period.
3. Disconnect a temperature probe at the terminals. Its Status should change to no_sensor or open_circuit, and Value should go null. Reconnect it and confirm it returns to ok.
4. Drive a sensor past its configured limit. Confirm OutOfLimits goes true, and false again once the reading is back inside the limit.
5. If the unit allows switching between C and F, change the setting. Confirm Unit follows byte 60 and the values rescale.
6. Unplug the M307 Ethernet cable. Confirm CommOK goes false within one poll plus the 5 s timeout and that a M307 poll failed warning appears in the gateway log. Reconnect the cable and confirm CommOK returns true with fresh timestamps on every value tag.

FAQ