Robot vision coordinates to ABB OmniCore: no PC EtherNet/IP server

You have the vision working on a PC: the camera finds the part and the algorithm returns position and orientation. The robot is an IRB 1200 on an ABB OmniCore controller with RobotWare 7, the manual on the desk says EtherNet/IP connects the controller to PLCs and other controllers, and the plan was to make the PC the server. That plan does not work — and the job does not need it. This guide gives the decision and the reasons behind it, a message format that survives a production shift, a worked size-and-rate example, the RAPID client steps and the go-live checks.

Why the EtherNet/IP option does not take a PC server

EtherNet/IP on OmniCore runs on the controller's main computer and needs no extra hardware. RobotWare gives the controller two roles on that network. A scanner is the client: it opens cyclic I/O connections and drives them. An adapter is the target: it holds a fixed block of input and output bytes, sized at configuration time, and answers whoever scans it. The scanner seat is written for a PLC or a second OmniCore controller, which is the pairing the application manual describes.

Your instinct about the roles was half right: the robot would indeed be the adapter, and the PC would be the scanner. What the manual rules out is not the direction of the data but the participant. A PC in the scanner seat means a licensed CIP protocol stack, assembly sizes agreed by hand, and coordinates packed as fixed cyclic bytes that arrive on the network's schedule rather than once per part. That is a lot of machinery to duplicate what one TCP listener does with the language you already have.

None of this makes EtherNet/IP wrong for the cell — only wrong as the PC-to-robot link. If a PLC owns sequencing, the robot joins as the adapter, and the adding EtherNet/IP devices to an OmniCore controller page walks that set-up. For PC to robot, keep reading.

The decision: the PC as TCP server, the robot as RAPID socket client

Run the vision PC as a plain TCP server and the robot as a socket client in RAPID. The robot side is language, not add-on machinery: SocketCreate, SocketConnect, SocketSend, SocketReceive and SocketClose are documented socket instructions in the RobotWare technical reference, and they speak ordinary TCP/IP to any host.

Give the server role to the PC for three practical reasons. The PC holds the fixed address, so the robot program never changes when the vision software is updated. The listener survives robot program edits and cold restarts. And the results are born on the PC, so the natural flow is one push per part. The robot calls SocketConnect with the PC's address and port, reads one line per part and keeps no server state at all. Add a second robot to the cell later and it connects to the same listener: you add a client, not a server.

The same pattern carries the wider hand-off. The RAPID walkthrough for receiving vision data over TCP sockets covers the receive loop in detail, and the step-by-step IRC5 socket exchange with a vision camera shows the same instruction family on the previous controller generation. On the PC side, the message format is the one in sending camera part coordinates to a robot controller over TCP.

Worked example: one pose message for the IRB 1200 handoff

The inputs, and where each comes from:

• Controller and robot: OmniCore with RobotWare 7, IRB 1200 — the job from the bench.
• Pose: x = 250.13 mm, y = -32.70 mm, z = 95.00 mm, quaternion q1-q4 = 0.7071, 0.0000, 0.0000, 0.7071 — illustrative values for a part near the middle of the calibrated frame, rotated 90° about z.
• Encoding: ASCII, comma separators, one pose per line, line-feed terminator.
• Pace: 10 parts/min, illustrative for a bench-top pick cell; substitute your own.
• Link: 100 Mb/s Ethernet or faster; any current port qualifies.

The rule: a message's size is its digits and signs, plus separators, plus the terminator — and the receive buffer should be at least five times the longest line, so one receive always covers one message.

The line 250.13,-32.70,95.00,0.7071,0.0000,0.0000,0.7071 plus its line feed counts out to 48 bytes: coordinates at 6, 6 and 5 characters, four quaternion fields at 6, six commas, one line feed. Standard Ethernet carries up to 1500 bytes in one frame, so the whole line arrives in a single TCP delivery, and one SocketReceive into a 256-byte buffer returns it complete.

The decision, with its threshold: bandwidth never constrains this link — 8 bytes per second against 12.5 MB/s of capacity leaves the wire idle better than 99.999% of the time. The binding limit is framing. Keep every line under the 256-byte buffer, one pose per line, terminated with a line feed. Append a part id and a checksum — 30 characters, say — and the line grows to 78 bytes, still comfortably inside the buffer. Past 256 bytes, shorten the message or raise the buffer with it.

The robot side in RAPID

The client is a handful of instructions. The address, port and timeout below are illustrative — use the PC's fixed address, a free port you have documented, and a timeout longer than your vision cycle.

VAR socketdev pick_link;
VAR string pose_line;

PROC connect_vision()
    SocketCreate pick_link;
    SocketConnect pick_link, "192.168.10.20", 50010;
ENDPROC

PROC get_pose()
    SocketReceive pick_link \Str:=pose_line \Time:=5;
    ! expect: 250.13,-32.70,95.00,0.7071,0.0000,0.0000,0.7071
    ! split on the commas, convert each field to a num,
    ! check the quaternion norm is close to 1, then move
ENDPROC

PROC close_vision()
    SocketClose pick_link;
ENDPROC

Behind the snippet:

1. Declare pick_link as a socketdev and pose_line as a string at module level, so every routine sees them.
2. Create and connect once per program start. The robot reaches out to the PC; nothing on the robot side listens.
3. Receive one line per part with SocketReceive ... \Str:= and a \Time:= timeout in seconds.
4. Validate before moving: exactly seven numeric fields, every field converted, quaternion norm close to 1. A short or malformed line stops the cycle, not the arm.
5. Write the received line with TPWrite during commissioning so you can see it whole.
6. Close the socket on program stop and recreate it on the next start.

Prove it on the bench: run the listener on a laptop, send the exact 48-byte line from the worked example, and confirm the pendant prints all seven fields with nothing left over. One clean receive proves the framing, the terminator and the encoding end to end.

The PC side: a small TCP listener

Yes, a Python script can do it: bind a listening socket, accept the controller's connection and write one line per pose with a newline at the end. The same shape works from C#, C++ or the scripting layer of your vision software. The full client-plus-calibration walk-through is in connecting a camera to a robot with Python: sockets and calibration.

On the plant floor that PC is usually a fanless controller bolted to the cell rather than an office tower. The vision controllers in the shop are built for the job: camera connections, the vision application and the robot listener in one box, with built-in light channels and I/O for the rest of the station.

Both cards below give the listener five or more LAN ports, so the camera network and the robot link stay on separate ports.

The MV-VC3301H-128G66 ships with a vision software license and PCIe expansion. The MV-VC5525-256G70-NN adds PoE camera ports, 32 GB of memory and 8 built-in light channels.

A two-camera cell with lighter vision runs on the compact MV-VC2140-128G40-1T: three or four LAN ports, 8 GB of memory and a 1 TB hard drive for image logs.

When the usual answer is wrong

A PLC already owns the cell. Then the PC talks to the PLC, and the PLC to the robot. Publish the coordinate array to the PLC in its own protocol — the Modbus/TCP register sizing for a vision coordinate array covers one common case — and run PLC to robot as EtherNet/IP with the robot in the documented adapter role. The same hand-off on another controller pair is worked through in the page on passing vision coordinates to a robot through a PLC.

The PC must supervise the controller. Writing RAPID variables, reading the pendant, starting and stopping programs from the PC — that is the PC Interface route with the PC SDK, a .NET library against controller data. It is heavier than sockets; choose it when the PC genuinely supervises the robot, not when it only hands over coordinates.

The job is conveyor tracking. A moving belt turns coordinate hand-off into tracking, and OmniCore has an integration path for external vision feeding its tracking application. The OmniCore EyeMotion external vision integration page covers that set-up; do not hand-roll a socket loop against a moving target.

The camera could live on the controller. If the vision is simple enough to move onto the robot side, the options for ABB integrated vision with a third-party camera lay out what the controller takes directly — one fewer host on the network.

Checks before go-live

• Addressing. Static IP on the vision PC; robot and PC on the same subnet or behind documented routes. The service port that worked on the bench is the commissioning port — move production traffic to a standard LAN port and leave the service port free for service tools.
• Firewall. The PC must allow inbound TCP on your port from the robot's address. The port and rule bookkeeping is the subject of vision controller to PLC: TCP ports and firewall rules.
• Freshness. A pose older than the part under the gripper is a mispick. Trigger per part rather than streaming — the stream-versus-snapshot failure mode is covered in vision locate works in teach but fails at run time — and tag each pose with an id, rejecting repeats. The ask-and-answer variant lives in triggering a USB camera capture from a robot controller over a socket.
• Frames and units. Millimetres, quaternion order q1-q4, one calibrated user frame shared by vision and robot. The coordinate bookkeeping on the robot side matches sending camera offsets to a robot over TCP socket messaging.
• Repeatability. Run 100 parts while the listener counts lines. Poses sent must equal lines received, with zero partial receives.

The decision for each case

• PC and camera straight to the OmniCore, no PLC between: the PC as TCP server, the robot as a RAPID socket client, one ASCII line per pose. EtherNet/IP stays out of it.
• A PLC owns sequencing: PC to PLC in the PLC's protocol, PLC to robot over EtherNet/IP with the robot as adapter — the option used as documented.
• The PC must supervise the controller: the PC Interface option with the PC SDK; keep sockets only for the coordinate stream if you still want one.
• Conveyor tracking with external vision: the controller's tracking integration, not a hand-rolled loop.

Shortlist the machine that hosts the vision and the listener from the vision controller cards above, or ask the applications team about the camera, lens and light around your part. The rest of the robot-side library — sockets, offsets, smart-camera hand-offs — sits in the robotics guides.