How to Set Electronic Keying on an EtherNet/IP Device

Back to Blog

Choose the Keying Level for the Situation

Decide the level from the system's needs, not from convenience. Compatible Module is the sensible default for normal operation: it fixes the vendor and product code so a wrong model is rejected, but tolerates a revision the device declares compatible, so an in-family firmware upgrade does not break the connection. Exact Match is for systems where the configuration must not drift - validated, safety-adjacent, or formally controlled installations - where any revision change should trigger a review anyway. Disable Keying is a last resort, appropriate only as a deliberate, documented exception.

The trade-offs behind each level are laid out in CIP electronic keying; this step is applying that judgment to the device in front of you. The question to answer before touching the tool is: do I need to catch firmware changes here (Exact Match), catch only wrong-model swaps while allowing firmware upgrades (Compatible Module), or - rarely and knowingly - accept whatever is present (Disable Keying).

Set the Expected Identity

With the level chosen, set the expected identity the connection will check. This means the vendor, product code, and, for keying levels that check it, the major and minor revision - the fields from the Identity object that the connection request carries. In practice the configuration tool populates most of this when you select the device from the catalog via its EDS, so the main decision is the revision you declare expected.

Set the expected revision to match the firmware actually installed on the device. For Exact Match this must be exact, so read the device's real revision and enter it. For Compatible Module you declare the requested revision and rely on the device to accept compatible revisions above it. Entering a revision that does not correspond to the installed firmware is the most common self-inflicted keying fault, so confirm the device's actual revision before committing the expected value.

Apply and Download the Configuration

Apply the keying setting as part of the connection configuration and download it to the controller so it takes effect on the next connection open. Keying is checked at connection establishment, in the Forward_Open, so the setting only matters when the connection next opens - after a download, a reconnect, or a power cycle of the path. There is no separate keying transaction; it rides the connection request.

Because keying is enforced at connect time, a change to the keying setting does not take hold until the connection re-establishes. If you change from Exact Match to Compatible Module to clear a firmware-mismatch fault, expect the change to apply when the connection next attempts to open, and be ready to confirm it there rather than assuming the download alone resolved it.

Verifying the Result

Verify by confirming the connection opens without a keying fault. A successful open with the intended keying level in force is the pass: the device matched the expected identity to the required degree and the I/O or explicit connection is running. If a keying fault appears, read its detail - it names which field did not match, so a revision mismatch points at firmware and a product-code mismatch points at the wrong module. The CIP general status codes frame these responses.

Confirm the resulting data is live, not just that the connection is green. A monitoring platform such as Merobix trends the controller's tags, so once keying is set correctly and the connection is up, the device's values should be updating normally in the recorded data. A connection that opens but whose data never refreshes is a different problem than keying, and seeing the tags move confirms the whole path is working, not merely that keying passed.

Common Mistakes

The most common mistake is disabling keying to make a fault disappear. That silences the symptom and removes the protection, so a genuinely wrong module would then be accepted - the opposite of what you want. Address the mismatch instead: install the correct part for a product-code mismatch, or update the expected revision for a firmware mismatch. Reach for Disable Keying only as a knowing, documented exception, never as a quick fix.

The second mistake is entering an expected revision that does not match the installed firmware, which manufactures a keying fault out of nothing under Exact Match. The third is forgetting that keying only takes effect at connection open, and concluding a change did not work before the connection has actually re-established. Choosing the right level, matching the real identity, and verifying at reconnect is the whole procedure.

Frequently Asked Questions