Skip to main content

Photon Feeder Setup: UUID Assignment and Address Conflicts Explained

· 5 min read
PikkoBot Team
PikkoBot Team
Precision Robotics

Photon feeders use UUIDs (Universally Unique Identifiers) to communicate with OpenPnP. This is generally reliable, but it creates a specific class of problems when feeders share IDs, get reassigned, or conflict with each other. If you've ever seen OpenPnP detect the wrong feeder or fail to recognize a feeder that's physically connected, UUID conflicts are the likely culprit.

Here's what's happening under the hood and how to fix it.

How Photon Feeder UUIDs Work​

Each Photon feeder has a unique identifier burned into its firmware during manufacturing. When you connect a feeder to OpenPnP, the software registers the UUID and associates it with a specific slot in your feeder setup.

The UUID serves as the feeder's identity on the USB bus. OpenPnP uses it to:

  • Map feeders to slots: "Feeder UUID abc123 is in slot 5"
  • Track component usage: "Slot 5 has used 47 components, 53 remaining"
  • Send commands: "Advance feeder in slot 5 by one index"

When everything works, UUIDs are invisible. You never think about them. When they don't work, everything breaks in confusing ways.

When UUID Conflicts Happen​

Scenario 1: Adding feeders after initial setup​

You set up 10 feeders during initial configuration. Three months later, you add 5 more. If the new feeders happen to have UUIDs that overlap with existing ones (rare but possible with firmware reflashes or replacement units), OpenPnP will get confused about which feeder is which.

Symptoms:

  • OpenPnP detects a feeder that you didn't connect
  • Feeder advance commands go to the wrong slot
  • Component counts don't match physical reality

Scenario 2: Replacing a faulty feeder​

A feeder develops a mechanical fault. You swap it with a new unit. If the replacement feeder has a UUID that's similar to another feeder in your setup (or if you accidentally assign the same slot), conflicts arise.

Symptoms:

  • The new feeder shows up with the old feeder's component assignment
  • Two slots appear to control the same physical feeder
  • Firmware update fails because OpenPnP targets the wrong device

Scenario 3: Multi-machine setups​

If you run the same OpenPnP configuration file on multiple machines (common in small labs), UUID conflicts are inevitable. Feeder UUIDs are machine-agnostic—they're physical device IDs, not software assignments.

Symptoms:

  • Feeder configuration from Machine A doesn't work on Machine B
  • OpenPnP crashes or hangs during startup
  • Feeders are detected but cannot be controlled

How to Reassign UUIDs​

Step 1: Identify current UUIDs​

Open OpenPnP and navigate to Feeders. Each feeder entry shows its UUID. Alternatively, use the Photon firmware tools to list connected devices:

photonctl list

This shows all connected feeders with their current UUIDs.

Step 2: Clear conflicting assignments​

In OpenPnP, delete the feeder entries that have conflicting UUIDs. Don't worry—you're not deleting the physical feeder, just the software mapping.

Step 3: Re-add feeders one at a time​

Connect one feeder at a time and add it in OpenPnP. This ensures each UUID is unique in your configuration.

Step 4: Update the UUID if needed​

If you need to change a feeder's UUID (e.g., to resolve a conflict without replacing hardware), use the Photon firmware flash tool:

photonctl set-uuid <feeder-id> <new-uuid>

Generate a new UUID with:

uuidgen

Step 5: Verify and save​

After reassigning, test each feeder individually:

  1. Select the feeder in OpenPnP
  2. Click "Feed" to advance it
  3. Verify the correct physical feeder moves
  4. Check that the component count updates

Save your OpenPnP configuration after verification.

Firmware Considerations​

Photon feeder firmware versions affect UUID handling:

  • Firmware v2.x: UUIDs are stable across power cycles but can be overwritten by firmware updates. Always back up your UUID assignments before updating firmware.
  • Firmware v3.x: UUIDs are stored in a protected memory region and cannot be accidentally overwritten. Recommended for multi-feeder setups.

If you're running older firmware, update to v3.x before expanding your feeder count. The upgrade process preserves existing UUIDs.

Troubleshooting Checklist​

When you suspect a UUID conflict:

  1. Run photonctl list — Compare output to OpenPnP feeder entries. Any UUID appearing twice is a conflict.
  2. Disconnect all but one feeder — Add feeders back one at a time, testing each.
  3. Check firmware version — Older firmware may have UUID stability issues.
  4. Verify USB connections — A loose USB connection can cause a feeder to drop and re-enumerate with a different (or default) UUID.
  5. Clear OpenPnP cache — Sometimes OpenPnP caches stale UUID mappings. Delete the feeder entries and re-add them.

PikkoBot's Pre-Configured Feeder System​

PikkoBot ships with Photon feeders pre-assigned and tested. Each feeder in a PikkoBot kit has a unique, documented UUID that's mapped to specific slots in the default OpenPnP configuration. This eliminates the most common setup headache: initial UUID assignment.

When you expand your feeder count, PikkoBot's documentation includes a UUID registry for your specific kit, making it easy to identify and resolve conflicts without guesswork.

The Bottom Line​

UUID conflicts are one of those problems that seem mysterious until you understand the underlying mechanism. Once you know that each feeder has a unique hardware ID and that OpenPnP maps IDs to slots, troubleshooting becomes straightforward: list your UUIDs, find the duplicates, and reassign.

Take 10 minutes to document your UUID assignments when you set up your feeders. Future you will be grateful.

For the full feeder setup process including slot configuration and the Photon protocol, see the Feeder Overview.

Need to calibrate after feeder changes? Check the Calibration Guide.