PLC fault code decoding for drive diagnostics

Decide what the diagnostic value means

Start with the diagnostic source description for the installed drive and its firmware revision. Obtain the applicable documentation from the manufacturer or an authorized distributor. A parameter name or connector number alone is not enough to establish the data format.

Different sources can represent different things:

• Latest fault number: the most recently recorded fault, which may remain available after the condition clears.
• Active fault number: a fault currently reported as present, according to the drive's documented behavior.
• Alarm number: a numeric identifier that selects an alarm description.
• Alarm bitfield: a set of bits in which each documented bit represents a condition. Several conditions may be represented together.
• Packed diagnostic word: one value containing two or more separate fields.

These formats need different decoding. A bitfield cannot be treated as a single message number. A latest-fault value cannot, on its own, establish that a fault is still active.

Write down the required meaning before changing the configuration. For example, “most recently recorded fault” is a different requirement from “fault preventing operation now.” If both are needed, provide separate fields and labels.

Trace the value from the drive into the PLC

Selecting a diagnostic source inside a drive does not automatically place it in a PLC data block. The communication configuration must carry that source in a defined transmitted position, and the PLC program must read the corresponding receive location.

A data block, often called a DB, is storage. Its address tells the program where to find a value, not what that value means.

Record the existing communication assignments before making changes. Replacing an outgoing value may remove a measurement or status signal that other logic already uses. Do not change control or safety-related mappings merely to make space for a diagnostic word.

Use the actual interface configuration to establish receive offsets and lengths. Do not assume that a drive's transmitted word number is also a PLC byte address. Confirm whether configuration offsets are expressed in bytes, words or another unit.

Keep the received diagnostic in a raw tag of the documented width before performing conversions. This gives you a comparison point independent of the message text.

Split bytes only when the documented format calls for it

Suppose the drive documentation defines a 16-bit diagnostic word with the alarm number in bits 0 through 7 and the fault number in bits 8 through 15. For that specific layout, the lower byte contains the alarm number and the upper byte contains the fault number.

The following is language-neutral pseudocode, not a program to download unchanged:

alarm_number = raw_word AND 16#00FF
fault_number = (raw_word SHR 8) AND 16#00FF

Use unsigned, 16-bit handling for raw_word and a logical right shift. Adapt the syntax and type conversions to the PLC programming environment. Some environments require an explicit conversion before a bitwise operation or shift.

The mask 16#00FF retains only the lower eight bits. Shifting right by eight positions moves the original upper byte into that lower-byte position.

For an arithmetic example, assume the received word is 16#1205. This is an invented value for explaining the calculation, not a diagnostic definition:

• The low byte is hexadecimal 05, giving alarm number 5.
• The high byte is hexadecimal 12, giving fault number 18 in decimal.
• The complete unsigned value is 256 × 18 + 5, or 4613.

This calculation identifies two numbers. It does not establish what either number means. That still comes from the applicable diagnostic table.

If the documented source instead contains one full-width fault number, splitting it into bytes would destroy its meaning. Decode the source you actually selected, not the format you expected to receive.

Check byte order before changing the decoding

The high byte and low byte describe positions within a numeric word. Their placement in a communication buffer or PLC memory also depends on the interface representation and how the program reads that buffer.

Compare the value at three points under the same stable diagnostic condition:

• The drive's diagnostic source or outgoing data monitor.
• The PLC's corresponding receive field.
• The raw diagnostic tag used by the decoding logic.

Display the raw values in hexadecimal when checking a packed word. Hexadecimal makes the two byte values easier to distinguish than a combined decimal value.

If the drive shows 16#1205 but the PLC raw tag shows 16#0512, investigate the interface's documented byte handling and the program's buffer interpretation. Do not add a byte swap simply because the resulting message looks more believable.

Also check signed conversions. A word with its highest bit set can appear negative when interpreted as a signed integer. That does not, by itself, mean the drive sent a negative diagnostic code.

Use a documented simulation facility, an approved commissioning procedure or an existing diagnostic condition for comparison. Do not deliberately create a hazardous machine fault to obtain a convenient test value.

Map numbers to documented text

A diagnostic number is usually an identifier, not a text message. Build the lookup from the documentation for the installed drive model and firmware. Preserve any prefixes or diagnostic classes needed to distinguish otherwise similar numbers.

Keep these elements separate in the application:

• The received raw word.
• The decoded alarm or fault number.
• The diagnostic class, such as alarm or fault.
• The matching description.
• Any documented active, historical or acknowledgment state.

Show the numeric code alongside the description. It remains useful if a translation is incomplete or the lookup table has not yet been updated.

Provide an explicit fallback such as “Unmapped fault code,” followed by the number. Do not convert an unknown code into “No fault.” Likewise, treat zero as “No fault” only when the source documentation defines it that way.

For a bitfield, map the documented bits individually rather than looking up the whole word as one code. Account for simultaneous conditions instead of allowing one message to conceal the rest.

Keep communication health separate from fault state

A stored PLC value may remain unchanged after communication stops. An unchanged latest-fault value may also be correct while communication is healthy. Comparing the diagnostic value with its previous value cannot reliably distinguish those cases.

Use the interface's documented communication status and an appropriate freshness mechanism. A receive-completion indication, update counter or source timestamp may help when the interface provides one. Choose any timeout from the configured update behavior and the application's requirements, not from an arbitrary display refresh interval.

Keep separate indications for:

• Valid data with no active fault, where the documentation supports that interpretation.
• Valid data with an active fault.
• Valid historical diagnostic data.
• Invalid or stale communication data.

If you retain the last received code after a communication loss, label it as the last received value. Do not present it as a current healthy state. A message lookup should never determine communication validity.

Make the displayed message match the diagnostic purpose

A useful diagnostic view shows the equipment identifier, code, description and whether the information is active, historical or unavailable. Label a latest-fault field as historical rather than shortening it to “Fault” and leaving its status ambiguous.

A fault description is not automatically a repair instruction. Keep recovery actions tied to the manufacturer's documented procedure and the machine's approved operating procedures. Do not couple message decoding to an automatic reset or a change in protective behavior.

If the decoded information will appear on a separate screen, define whether that screen is only a summary or part of the operating interface. The distinction between a factory status display and an operator HMI matters when acknowledgment, response timing or machine interaction is involved.

The final acceptance check is simple: under an approved, stable diagnostic condition, the drive indication, PLC raw value, decoded number and displayed description must agree. Check the communication-loss indication separately. A correct-looking sentence is not enough to prove the receive mapping is correct.

Questions