GE EGD Troubleshooting Guide

Overview

This guide covers the most common GE EGD gateway failures Chipkin is likely to see: missing exchange definitions, BOOL or bitfield mapping problems, and cases where the source exchange is healthy but the chosen target protocol adds complexity. The strongest internal example followed exactly that pattern: GE EGD source data was validated, but the preferred EtherNet/IP destination did not resolve and the project fell back to Modbus.

Diagnostic Flow

1. Confirm Producer ID and Exchange ID.
2. Confirm the exchange layout from the source PLC side.
3. Confirm data typing and any bit-level interpretation.
4. Validate one known-good source value.
5. Only then troubleshoot the downstream target protocol.

Symptoms & Solutions

Symptom	Likely Cause	Action	Related Page
The gateway is online but the mapped points make no sense	The exchange definition or data typing is wrong	Recheck the source exchange layout before changing the target side	GE EGD
BOOL or bit values are scattered or shifted	Bit-level mapping does not match the target interpretation	Revisit the chosen word and bit strategy	Modbus
The GE side looks healthy but EtherNet/IP still fails	The target-side protocol is adding its own complexity	Separate GE EGD validation from EtherNet/IP troubleshooting and evaluate fallback options	EtherNet/IP
The team knows the PLC but not the exchange	Intake is incomplete	Stop and collect the controller export before deeper troubleshooting	GE EGD
One target protocol fails while another works	The source exchange is valid, but the preferred target path is less forgiving	Validate against a simpler target before assuming the source is broken	Modbus

The Exchange Definition Is Missing

This is the first thing to fix in any GE EGD job.

Confirm The Source Model

Confirm:

• Producer ID
• Exchange ID
• Payload layout
• Which words, bits, and types matter to the target system

[!WARNING] If the exchange definition is missing, everything after that becomes guesswork.

Data Types Do Not Translate Cleanly

GE EGD troubleshooting often looks like a target problem when it is really a mapping problem.

Recheck The Value Model

Look again at:

• BOOL and bitfield handling
• UINT and packed-data expectations
• Whether the target PLC or BAS expects a different shape than the source exchange provides

The Target Protocol Is Harder Than The Source

Not every downstream protocol is equally easy to validate, and GE EGD jobs should be scoped with a fallback mindset when the destination path is unusually demanding.

Prove The Source First

Confirm:

• One known-good value from the GE EGD side
• Whether a simpler target such as Modbus works cleanly
• Whether the preferred target is failing for reasons outside the source exchange itself

Quick Diagnostic Decision Tree

• Start by confirming Producer ID, Exchange ID, and the source payload layout.
  • If that is unclear: stop and collect the exchange definition first.
  • If it is clear: continue to type validation.
• Check whether the data types and bit handling are documented.
  • If not: define them before reworking the gateway map.
  • If yes: continue to source-value validation.
• Check whether one known-good source value translates correctly.
  • If not: fix the GE EGD mapping first.
  • If yes: continue to target-side troubleshooting.
• Check whether the preferred target still fails while a simpler one works.
  • If yes: treat the target protocol as the main issue.
  • If no: the main fault was on the GE EGD side.

Related Pages

• GE EGD
• Modbus
• EtherNet/IP
• BACnet
• QuickServer