Skip to main content

LumenPnP Feeder Compatibility: Three Checks Before You Buy

A feeder for a LumenPnP-platform machine is a metal and plastic assembly plus a firmware load, and it sits at the far end of a chain that starts at your controller. The mounting is the part people check when they compare listings, and it is the part least likely to be the problem.

A LumenPnP feeder is not locked to a LumenPnP​

Opulo designed the feeder for the LumenPnP, and it mounts on any 20 mm × 20 mm v-slot extrusion. It holds tape down to 0402 parts. On a 50-slot machine, an 8 mm or 12 mm feeder takes one slot and a 16 mm or 24 mm feeder takes two.

Photon is firmware that runs on the feeder, and the project is written to support several hardware designs, so a feeder from another maker can run it. Opulo describes the resulting portability as feeding the Photon protocol "over RS-485 to any Marlin host with RS-485 support". Your rail answers the mechanical half of a compatibility question and your controller answers the electrical half. When a seller writes "compatible", ask which half they mean.

Check one: the firmware, not the shape​

A listing photo tells you the feeder will mount. The protocol behaviour tells you whether it will ever answer.

The first probe in a bus scan is GET_FEEDER_ID (0x01), sent to each unicast slot address in turn and answered with a 12-byte UUID. Ask a seller whether their feeder answers it, then ask what GET_VERSION (0x03) returns, which is the protocol version a feeder reports once it is initialized.

The command set has eleven IDs: 0x01 to 0x06 for the standard operations, 0xBF (VENDOR_OPTIONS) for anything a maker adds on top, and 0xC0 to 0xC3 for the broadcast commands that find a feeder by UUID, flash its indicator light, program a slot address, and list feeders that are not yet initialized. A feeder that implements part of the set passes the address probe and fails later, at INITIALIZE_FEEDER (0x02), which is a harder failure to read from the symptom.

Opulo ships feeders with firmware already loaded. To read the version off a feeder, hold both buttons: a single green flash means v1.0.3 or newer, a red flash means beta firmware, and a light that stays on with no flash means v1.0.2 or earlier, where the documented advice is to update.

Check two: the host has to speak the bus​

The Photon page on the OpenPnP wiki is direct about the host side: the packet structure is currently only supported by Marlin, using the M485 command.

OpenPnP sets that up when it needs to. If a PhotonFeeder exists in the machine, OpenPnP creates an actuator called PhotonFeederData and writes two things onto the first GcodeDriver it finds: the read command M485 {Value} and the reply regex rs485-reply: (?<Value>.*). Two consequences follow. A controller that is not a Marlin host with RS-485 has no route to a Photon feeder at all. A machine with more than one GcodeDriver gets the pairing on the first one only, so the rest is a manual edit.

If the machine is not LumenPnP-platform hardware, Opulo documents the alternatives on a standalone control page: the LumenPnP motherboard with a slot harness, or an STM32F407 development board with an RS-485 transceiver, Marlin loaded, and a separate 24 V supply for the feeders. A plain USB-to-RS-485 dongle is described there as something people have used for debugging, "but not for regular communication during a job", and it needs the OpenPnP reply regex changed.

Check three: the slot is part of the answer​

A Photon feeder works out where it is from the slot it sits in. On LumenPnP hardware, each slot carries a 1-Wire EEPROM programmed with the slot address, and the feeder reads that address when it is mounted. That is what lets a feeder keep its part assignment when you move it to another position on the rail.

The slot hardware supplies the 24 V as well as the data. The slot harness kit contains 49 feeder slots, one termination slot, a programmer, 50 screws and 50 T-slot nuts, and the moulded slot numbers are the addresses. Slots mount in order, the differently coloured slot 50 connects last in the harness, and slot 1 sits 85 mm from the front left leg.

Build your own rail and the address has to be written once per slot, using PROGRAM_FEEDER_FLOOR (0xC2). OpenPnP ships a wizard that programs slots through a single mounted feeder. One number matters if you are planning a longer rail: OpenPnP's PhotonFeeder describes a physical slot numbered 1 to 254, while its maximum feeder address property defaults to 50. A 60-slot rail works, with that property raised.

What a mismatch looks like in OpenPnP​

Where a feeder compatibility check can fail

These failure modes are not equally loud, and three of them produce no message at all. A feeder that mounts and then does nothing is worth diagnosing from the host downwards.

What you seeWhere it brokeWhy
Feeder missing from the scan, nothing in the logframing or CRCA reply is discarded when the payload length disagrees with the header, when the CRC8 does not match, or when the packet ID does not match the request. Every one of those is reported as no response.
A second feeder entry for the same slotUUIDThe slot can answer WRONG_FEEDER_ID (0x01) on INITIALIZE_FEEDER. OpenPnP then adds a feeder for the UUID that answered and assigns it that slot, so one slot ends up with two entries.
Failed to find and initialize the feederfirmwareThe find-and-initialize pair is retried with FeederCommunicationMaxRetry, which defaults to 3, so four attempts before the error.
Photon Feeder with address ... has no address. Is it inserted?slot or EEPROMNo slot address was read back.
The slot at address N has no location configured.slot setupThe slot has no saved location.
Photon Feeder with address ... has no location offset.feeder setupThe feeder's own offset field is empty.
Feeder timed out when we requested a feed status update.feed status pollingThe poll bound is three times the expected feed time the feeder reported, checked every 50 ms.
Feeder could not reach its destination.mechanicsThe feeder answered COULD_NOT_REACH (0x02).
Feeder scans in, is configured, still will not enableconfigurationFive fields have to be filled: hardware ID, part, slot address, offset, and the slot location.

Status codes that do not map cleanly​

Photon documents eight status values: 0x00 OK, 0x01 WRONG_FEEDER_ID, 0x02 COULDNT_REACH, 0x03 UNINITIALIZED_FEEDER, 0x04 FEEDING_IN_PROGRESS, 0x05 FAIL, 0xFE TIMEOUT and 0xFF UNKNOWN.

OpenPnP's error enum carries the first five, has TIMEOUT commented out, and has no entry for 0x05. Anything it does not recognise becomes UNKNOWN (0xFF). In the feed loop, only OK returns and only COULD_NOT_REACH throws. Every other value falls through and the loop keeps polling until the time bound runs out. A feeder that reports FAIL therefore arrives at the job as a feed timeout, which reads like a bus problem rather than a feed problem. When a job stops on a feed timeout, look at the feeder's own indicator light and tape path before re-terminating the harness.

For anyone writing firmware against this protocol, one detail in the documentation is worth knowing. The protocol page's MOVE_FEED_STATUS section lists COULDNT_REACH as 0x01, while the status table on the same page and OpenPnP's enum both use 0x02. Follow the table.

How this lands on a Vertex 4​

A Vertex 4 runs a Marlin-firmware mainboard on 24 V with 50 slots, and its rail matches the LumenPnP rail dimensionally, so a Photon feeder mounts and turns up in a bus scan with no wiring work. Both halves of the compatibility question are answered by the machine rather than by the feeder.

PikkoBot powered feeder four-pack on the Vertex 4 rail

PikkoBot sells the Photon feeder as a steel-plate powered feeder four-pack at $299 for 8 mm and 12 mm, $319 for 16 mm and $329 for 24 mm, alongside an AS2 servo feeder line at $199 for a four-pack, or $219 as an 8 mm starter kit that adds the FD_USB_HUB tool board and an AS_FCB_V1.0 16-channel control board.

The AS2 line follows the 0816 feeder design and drops onto the same rail, and it runs its own controller rather than Photon firmware. It will not answer a Photon bus scan, and it needs its own driver and actuator configuration in OpenPnP. Same tape, same slots, a second software path.

What to ask a seller​

Three questions cover most of the risk.

  1. Does the feeder run Photon firmware, and what does GET_VERSION (0x03) return?
  2. How is the slot addressed? Does the rail carry a programmed EEPROM per slot, or does the feeder need its address written some other way?
  3. What does the machine's controller run? Marlin with RS-485 support means the standard path. Anything else means reading the standalone control page and budgeting time for debugging.

Vague answers are a scheduling problem rather than a hardware problem. The likely outcome is a feeder that mounts, sits in the machine, and never answers on the bus.