How the Integration Works — Standard Interfaces, No Custom Engineering
The ABB robot extracts packaged goods, polybags, paper bags, foil packaging from containers, cartons, or a conveyor belt. It hands them off directly to the ferag.skyfall induct station. From that point, the goods enter ferag’s own material flow logic. Identification, buffering, and sorting all run on the sorter’s existing control layer.
Hanging garments (GOH) skip the robot entirely. They enter through a separate infeed instead. This keeps the automated pick station integration flexible, rather than locking the whole line into one packaging format.
The interface between the two systems uses standard identification methods: RFID, QR, and barcode scanning. This gives 100% traceability at the handover point. For an integrator, that’s what matters most. The robot and the sorter don’t need a proprietary protocol between them. As a standard interface pouch sorter, the induct station doesn’t need reconfiguring for every new robot brand.
Reducing Manual Picking Without Re-Engineering the Sorter
At 1,000+ picks per hour, the robotic front end takes over induction work. Without it, that work would need extra manual labor at the input side. Nothing changes in how ferag.skyfall itself operates. The sorter’s dynamic buffering and matrix sorting logic simply manage the variable throughput coming from the robot, the same way they’d manage manually inducted goods.
This is the real benefit for projects that want to reduce manual picking at the input side: the robotic picking layer can scale, swap, or upgrade on its own. A project that starts with manual induction can add third-party robot integration later. Or it can switch robot suppliers entirely. Either way, the ferag.skyfall configuration underneath stays untouched.
Why System Integrators Specify ferag.skyfall for Mixed-Vendor Architectures
This ABB integration is one example of a broader pattern. ferag.skyfall is built to sit inside automation architectures it didn’t design end-to-end. It connects to any WMS or WCS through standard interfaces. As this case shows, it connects to third-party robotics the same way. For integrators, that means the sorter isn’t a single-vendor dependency. Picking, storage, and control layers can each be sourced, specified, and updated on their own timeline.
That matters most when the robotics roadmap and the sorting roadmap move at different speeds. New picking hardware becomes available. Or a customer standardizes on a preferred robotics vendor mid-project. Because this automated pick station integration is proven rather than custom-built per project, it lowers integration risk and shortens the engineering phase.
ferag.skyfall vs. Building a Custom Robotic Interface
The alternative to this approach is building bespoke interface logic for every robot brand a project might use — a cost most integrators would rather avoid repeating. Because ferag.skyfall’s induction, identification, and buffering logic stay constant regardless of what feeds the induct station, that engineering effort is paid once, not per robot vendor.
Combined with skyfall.controls for real-time execution and doWarehouse WES/WCS for orchestration across the wider system, the robotic front end becomes one more standard input rather than a special case.
For integrators scoping a similar project, ferag.go is a fast way to check early on whether a ferag.skyfall-based concept fits the throughput and space requirements — before committing to a specific robotics partner.
