Yes, a P2K can read and write CAN and AS-i devices through an HMS Anybus gateway. It does not see those devices as nodes on its own network. The gateway is master on the fieldbus side and a plain EtherNet/IP adapter or Modbus TCP server on the Ethernet side. It shuttles a fixed block of bytes between the two. The P2K only ever sees that byte block. Get it running with that model in mind, then tidy up the mapping.
Skip the Quick Fixes That Don't Work
These are the first things people try when a new gateway sits between a P2K and a fieldbus. None of them work:
- Browsing for CAN or AS-i nodes from the PLC software. The P2K has no CAN or AS-i driver. It finds one Ethernet device, the gateway, and nothing behind it.
- Configuring only the PLC side. An EtherNet/IP connection to the gateway can come up healthy while the fieldbus side has no masters, no slaves, and no mapping. You get a green link and all-zero data.
- Buying a gateway labelled "CAN" without checking the protocol. CAN is only a physical and data-link layer. CANopen, J1939 and raw CAN frames each need a different gateway or configuration. A mismatch never talks to the devices.
- Guessing register or assembly sizes. If the P2K's connection size differs from the gateway's configured I/O size, the EtherNet/IP connection is refused. On Modbus you read the wrong data with no error.
- Expecting to set up the field devices from the PLC. Node IDs, baud rate, PDO mapping and AS-i slave addresses are set in the gateway's configuration tool or with field tools. The P2K program never sets them.
Understand What the Gateway Actually Does
An Anybus gateway is a data mapper with two independent network interfaces:
| Side | Role of the gateway | Configured in | What it exchanges |
|---|---|---|---|
| Ethernet (to P2K) | EtherNet/IP adapter or Modbus TCP server | HMS configuration tool, plus the P2K hardware/comm setup | Fixed-size input and output byte arrays |
| CAN / CANopen / J1939 | Bus master or node | HMS configuration tool | Messages, PDOs or PGNs mapped into those arrays |
| AS-i | AS-i master | HMS configuration tool | Slave I/O bits packed into those arrays |
The P2K acts as EtherNet/IP scanner or Modbus TCP client. It writes its output block to the gateway and reads the input block back on each cycle or RPI. The gateway runs its own fieldbus scan in parallel and copies data between the fieldbus and the byte arrays. Nothing passes through transparently. Every bit the PLC sees has to be mapped to a byte and bit offset in the gateway configuration.
This has two consequences. Diagnostics for the fieldbus live in the gateway, not the PLC. Adding a device on the fieldbus means changing the gateway mapping and usually the P2K tag layout as well.
Pick the Right Gateway for Each Bus
For a trainer that covers several buses, plan one gateway per fieldbus. Pick the Ethernet protocol on the P2K side to suit the lesson:
| Decision | Choose | Why |
|---|---|---|
| Cyclic I/O, fixed update rate | EtherNet/IP (implicit) | Connection-based, set RPI, connection fault is visible in the PLC |
| Simple setup, easy to see register by register | Modbus TCP | Plain holding and input registers, polled by the P2K client |
| CAN devices from industrial vendors | CANopen master gateway | Most industrial CAN I/O and drives speak CANopen |
| Vehicle or engine controllers | J1939-capable gateway | PGN-based messaging, not CANopen |
| Custom or raw CAN frames | Gateway that supports raw CAN ID mapping | You define IDs, DLC and transmit triggers yourself |
| AS-i sensors and actuators | AS-i master gateway plus AS-i power supply | Gateway is the master; the bus needs its own dedicated supply |
Check the field devices' datasheets for the exact protocol before you order anything. That single check prevents most dead-on-arrival gateway installs.
Build the Link Step by Step
- Wire the fieldbus side first. For CAN, fit 120 ohm termination at both physical ends of the trunk only. For AS-i, power the bus from an AS-i power supply, not a standard 24 V DC unit.
- Set field device identities. Give each CANopen node a unique node ID and a common baud rate. Give each AS-i slave a unique address with an addressing tool, because new slaves ship at address 0.
- In the HMS configuration tool, set the gateway as fieldbus master. Add each device and map its I/O to byte offsets in the gateway's input and output areas. Write the map down as a table of offset, length and meaning.
- Set the Ethernet side in the same tool: IP address, subnet, protocol, and the total input and output sizes. Download the configuration and confirm the fieldbus status LEDs show a running bus.
- In the P2K project, add the gateway as an EtherNet/IP adapter or a Modbus TCP server. For EtherNet/IP, take the assembly instances and sizes from the gateway's EDS and configuration. For Modbus, set the register start addresses and counts to match the gateway map.
- Create P2K tags that mirror your offset table. Unpack bits and words from the arrays in logic, not by guessing offsets in the HMI.
- Set the gateway's fault action for loss of the Ethernet connection (clear or hold outputs) and match it to what the machine needs.
Prove the Data Path End to End
- Confirm the connection or poll status in the P2K is healthy, with no timeout or size-mismatch fault.
- Force one output bit in the P2K. Watch it change in the gateway's live data view, then at the physical device.
- Trigger one input at a device. Watch it in the gateway live view, then in the P2K tag.
- Repeat for one analog or 16-bit value. Check byte and word order, because Modbus registers are 16-bit and 32-bit values often come in word-swapped.
- Pull the Ethernet cable. Outputs should follow the fault action you set in step 7 of the build procedure.
- Disconnect one fieldbus device. The gateway's status or diagnostic data should flag it. Map that status into the P2K so the program can see a device drop.
If a bit shows up in the gateway live view but not in the PLC, the problem is the Ethernet-side mapping. If it doesn't show up in the gateway live view, the problem is on the fieldbus side.
Avoid the Traps That Keep Coming Back
- Stale data looks valid. A dead fieldbus behind a live Ethernet connection can leave inputs frozen. Map the gateway's status word or a live counter and alarm on it.
- Offset drift after edits. Inserting a device in the middle of the gateway map shifts every later offset. Append new devices at the end, or update the P2K tags in the same session.
- Duplicate addresses. Two CANopen nodes with the same ID, or two AS-i slaves at the same address, cause intermittent faults that look like wiring problems.
- Size changes need both ends. Any change to the gateway I/O size must be made in the P2K connection too, or EtherNet/IP refuses the connection.
Stop here if the gateway's own tool cannot bring the fieldbus to a running state with the correct devices. That is a gateway or device issue, and HMS support is the right call. If the gateway live data is correct but the P2K cannot connect with matched sizes and IP settings, collect the P2K communication status and call AutomationDirect support.
FAQ
Can a Productivity2000 PLC talk to CANopen devices directly?
No. The P2K has no CAN interface. Put a CANopen master gateway between them and exchange the mapped data over EtherNet/IP or Modbus TCP.
Does the P2K see individual AS-i slaves through an Anybus gateway?
No. It sees one block of input and output bytes from the gateway. Each AS-i slave's bits sit at the offsets you assign in the HMS configuration tool, and you unpack them into tags in P2K logic.
Can I use Modbus TCP instead of EtherNet/IP between the P2K and the gateway?
Yes, if the gateway model supports Modbus TCP on its Ethernet side. The P2K polls registers as a client, so match register addresses and counts to the gateway map and check 32-bit word order. EtherNet/IP gives you a fixed RPI and a visible connection fault, which Modbus polling does not.