Designing a Feeder Protocol

A tremendous thank you to all of the open-source contributors that helped figure out how to talk to feeders! We've got a great system set up, and one that will let us do all kinds of cool things with feeders (and other peripherals) in the future.
You can get a LumenPnP kit here!: opulo.io/
Excellent video from Ben Eater describing CRCs:
• How do CRCs work?
Footage courtesy of:
• Happy New Year!
-------------------------------------------------------------------
Check out my Patreon:
/ stephenhawes
Join the STR Discord Server:
discordapp.com/invite/TCwy6De
LumenPnP Github Repo:
github.com/index-machines/index
Opulo Site:
opulo.io/
-- FOLLOW --
Twitch bit.ly/stephen-twitch
Instagram bit.ly/stephen-instagram
Twitter bit.ly/stephen-twitter
-- GEAR --
These are affiliate links so if you buy anything through them I get a small percentage which helps out the channel. Thank you!
PCB Holder: amzn.to/344qhVD
Microscope: amzn.to/348aSnw
Soldering Iron: amzn.to/2KlHDGs
Wire Strippers: amzn.to/2IESgDV
Cutting Mat: amzn.to/3oNCwOz
Flush Cutters: amzn.to/3ncFwnc
Digital Calipers: amzn.to/3gIzZSL
Leatherman Sidekick: amzn.to/3a4sQuY
Part Organizer: amzn.to/3a9uDyV
Soldering Iron Tip Cleaner: amzn.to/3a3wZiD
Oscilloscope: amzn.to/2W4zrNt
Multimeter: amzn.to/2JVp6Ba
Crimping Tool: amzn.to/37WymwP
SpaceMouse: amzn.to/3gCWR64
Tweezers: amzn.to/3a1auL5
Solder Wick: amzn.to/347kUVI
Files: amzn.to/37bMXp0
Dremel: amzn.to/3gIADj9
Headlamp: amzn.to/3gE5VYw
Pelican Case: amzn.to/3ncFpbg

[@a4d9]

Add a protocol version in the header (maybe as the first byte). You will enjoy this later (for example when you update the protocol and forgot to update the firmware in the feeders, or you want to connect something other to the same bus)

[@Nifty-Stuff]

Stephen, please NEVER stop making videos! I'm not even interested in ever making a pick machine, but your on-screen personality, skills, and excitement about the project are just too much fun and interesting not to watch. So ya, keep up the great work and keep making these videos forever! :)

[@jurgenaddicks1634]

I completely agree with this statement ! 👍

[@AJMansfield1]

The feeder ID tracking system you've outlined seems like it's actually completely counter to the way you'd want to use feeders in production. The workflow I'm imagining is that you'd want to have one spare feeder that's not installed in the machine that you can load offline with the next reel of whichever part is about to run out, and then quickly swap that fresh feeder in once the running feeder feeds its last part. Then, the removed feeder becomes your spare, and you load it with whichever the next reel after that is to swap in for a third feeder. With the system you've described, you'd then have to countermand OpenPNP every single time to tell it that the feeder you just loaded into the 10k resistor slot _does_ actually have 10k resistors rather than the 100nF capacitors it had in the slot you swapped it out of. Letting feeders flexibly reassign themselves as holding the same part as the last feeder that got removed is a desirable, even necessary, feature. An even more production-friendly option, though, would be to build some sort of external programmer tool that incorporates a barcode scanner for scanning a reel's barcode, and program the feeders with some sort of direct part number / BOM line number / virtual slot number every time you load a new reel. So when reloading the spare feeder offline, you can set it up to instantly be recognized as the correct item the moment it's installed into the pick-and-place. Then, when openPNP goes to pick a given part, it can just look for _any_ feeder that matches the part it's trying to feed -- perhaps based on fewest remaining (let feeders track their own part counts?), or perhaps shortest travel distance, allowing you to potentially even install the second feeder full of a part _before_ the first feeder runs out. This would even allow you to set it up for OpenPNP to prompt you to exchange one feeder for another one containing the required part, to allow it to assemble boards with more BOM items than it has feeder slots.

[@MiggyManMike]

"feeders gota feed" needs to be merch :D

[@YourSelft487]

I'm working everyday with PNP machines and seeing your improvement is really fascinating. The way you've made the feeders and the way they communicate is exactly how they do in professional machines, the feeders are juste quicker, steadier and thinner (about 10mm width for 8mm band). Keep-up working on this Open project and keep uploading videos about it :D

[@derekkonigsberg2047]

Given that nearly every PNP discussion thread says "the feeders are the hard part, the rest of the PNP machine is easy" I very much wish you luck.

[@JoeyRay82]

I really enjoy your video format and the progress you make! Here is an idea to get rid of that EEPROMs and manual addressing procedure by using simple a Flip-Flop IC on each position. Connect all of them in a row. The individual feeders can connect to the output of the Flip-Flop on their position when mounted. The main controller can shift a "1" through each position as kind of a chip select. If a feeder is connected and has it's select pin on high, it can send a message to the controller with its information and/or wait for commands and reply while other feeders ignore messages on the bus. You save that EEPROM stuff including that manual configuration, you can get rid of addressing and your protocol can be simpler. There are even fancier possibilities in that case, like talking to multiple feeders at the same time by shifting a sequence through. Additionally, you could connect the last Flip-Flop back to the controller. This makes it possible to check that the signal gets passed correctly and the controller can determine the number of available positions. No hardcoding necessary. The disadvantage of this approach would be the two additional signal lines of which one has to be daisy chained.

[@scooterareyouready3535]

There's "fake" all over his face and expressions, especially looking into his eyes. Wouldn't trust him to tell you your idea is a better way. I've been analysing him for a while. Seems his motives are of non-pure intent and he struggles for the consumption of power.

[@TradieTrev]

Loving that you're designing this in such a way to make it user friendly. Keep up the good work team!

[@BillieRuben]

Ahhh, Justin is great! :D Both entertaining and informative! :D More Justin please!

[@justaddjeff1988]

Cool! Pretty much what I did with my Sumo robot and it's i2c bus back in 2006. It searched for motor drivers, LCD and ultrasonics.

[@Irilia_neko]

I so happy to see all the progress in this project/product ^^

[@da_vics]

Been following this project for a while now! I love the progress so far! :)

[@Worldwarrior01]

Keep up the great work, glad your back to the R&D

[@seanpelletier2637]

I love watching this stuff, I am in R&D myself and was originally looking at building my own system using openPNP but you guys are doing all the stuff I would love to do, I CAN'T WAIT until your kits are available, or at least the electronic part, I am going to build my own hardware since I have a CNC shop... again, really really interested in getting the motherboard and feeder boards!

[@der.Schtefan]

How cool to see this all fall into place :)

[@harryman01]

Finally an update 🥰 about the feeders

[@roedyhellyeah]

cant wait to order and build the feeders

[@nielspaulin2647]

Good ideas!

[@noel1637]

Any plan to make a narrower version of the 8mm feeders? How many of them can fit on the rail?

[@AJB2K3]

I like the idea off shuffling headers about mid run and not have to reprogram everything.

[@kentswan3230]

Stephen, With the current feeders how and when is a feeder associated with a bom part id and the part size?

[@MrRedwires]

Honestly, this is absolutely fantastic to see and hear! Hotswap feeders would allow for really complex assemblies because it should be possible to swap between different sets of parts if the available space is not enough, correct? I might need to recommend getting a PnP at my internship place, the Wendelstein Stellarator. Apparently all they have now is a very basic hot air reflow workstation, and we can't have that :P

[@hardwareful]

Too bad the feeders are limited to 8 bit and there's no protocol version information in the header. Would also have liked to see forward error-correction.

[@der.Schtefan]

There is no need for FEC. if the data is corrupted it can be retransmitted within microseconds. This is not a space probe.

[@crenn6977]

It is highly unlikely that the packet header needs protocol version information but if it's needed, it can be implemented with the payload (data) messages. It's also unlikely that there will be 255 feeders connected to a single machine, so single byte addressing is fine in this case.

[@davidf2281]

Nice vid. Curious as to why the feeder-floor address isn't just programmed with a DIP switch?

[@crenn6977]

IO requirements and vibration. A single wire to do the ID was a good compromise.

[@petermuller608]

So many people reinventing the wheel with regards to protocol encoding, especially with regards to forward compatibility instead of using a proven implementation like protobuf

[@Inf04U]

u got my sub true talk here

[@reedzik]

im interested in your frame , do you have stl any where for thoose x axis mounts ?

[@oswynfaux]

I was thinking you need a way to index the feeders physical, perhaps fiducials and a QR code on the end of each feeder so it knows what feeder it is and so it can zero in on the part pickup window

[@i_might_be_lying]

R&D is easy if you think about all the possible functionality that users might want and about all things that can go wrong before writing software. And also don't write software with bugs, because creating bugs is a choice!

[@qwertymodo]

You say creating bugs, I hear creating jobs.

[@glowing_kitty]

What a funny timing. I also just started to think about how to communicate between two devices and what kind of protocol to use. But in my case it’s simpler (in theory), I just want a control unit with an esp32 recognize what LED lamps (up to 8 at the same time, which also have esp32 chips inside) are connected to it and then automatically update the settings of the WLED settings of the control unit (how many LEDs, on what gpio pin, with what power supply). Currently thinking about testing out I2C for that? Together with some kind of repeater chip, to also make this work over 3-5m distance?

[@JoeyRay82]

I2C isn't really meant for distance because of emi and it's low voltage. Ideally something is needed to either change voltage level (kind of like in uart via RS232 transceivers) or to send the data over differential pairs (like CAN, RS485, etc.). Optical would also be an option. Repeaters are possible, but also may suffer from emi. Otherwise i would recommend reducing the baudrate as low as possible and designing a protocol on top of I2C that can detect errors and also corrects them. Implementing a reliable I2C slave can be tricky too. esp32 has wifi and bluetooth. Is that no option in your case (at least wifi/espnow)? Or a combination out of gpio and wifi?

[@glowing_kitty]

RS485 looks fairly simple to implement, both hardware and code wise. I don’t need a high data rate, in fact it’s just a simple string of maybe 50 characters at most I would guess, which needs to be transferred reliable one time over a distance of up to 5m. Wifi or Bluetooth aren’t really options because I am concerned they will interfere with WLED running at the same time (which controls the LEDs connected to the esp but also uses wifi for hosting a local web server, to allow the easy control of the LEDs via the web browser. Are there any advantages / disadvantages of CAN vs RS485 I should be aware of? And can they use any GPIO pins or have to use specific ones?

[@misterm1502]

As all chips are esp's take a look on the ESPnow protocol which is wireless and should suit your needs perfectly Pardon, have not seen your response that wireless ways might interference with your leds. But anyhow you could give it a try if you have it running on a breadboard

[@JoeyRay82]

@@glowing_kitty CAN is a good choice if the MCU has hardware support for it (as it does case of the ESP32). In that case you only need a bus driver and some terminating resistors. All protocol stuff is handled for you (even resends on bus collision). Instead of addresses it uses message ids, which can be kind of used as addresses, but also allow for broadcasts for example. messages have a max payload of 8 bytes. RS485 is as far as I know only the physical interface. Like for UART you have to come up with your own protocol. If you have multiple senders at the same time you have to take care of collisions yourself. Profibus is a common protocol on top of RS485 for example.

[@enjoying28]

maker buy has ad of your machine running on this video.

[@randycarter2001]

The way I like to describe protocol. We have decided to communicate by creating random vibrations in air with our mouths. We will then receive those vibrations with our ears. Protocol is, "What language do we speak?" What does Arbol, Arbre, Strom or Tree mean?

[@3nt3_]

why don't you just use an existing protocol like CAN?

[@chaitanyasindagi1237]

Why wouldn't you guys just use CAN bus? It sounds like you've basically homebrewed the entire CAN protocol. The request-response method is basically what CANopen does

[@JoeyRay82]

I guess it's because he initially used an ATMEGA328P that is lacking native CAN support and they don't want to redesign. But I agree with you.

[@hamjudo]

I am guilty of that sin. This probably won't be a surprise, but my reinvented CAN bus was much worse.

[@bj_]

There has to be a more efficient method for discovering devices that doesn't involve querying the line for every address

[@Belginator]

Look at Mydata feeders

[@Graham_Wideman]

Why those feeders in particular?

[@Belginator]

@@Graham_Wideman They do not need peel back the plough the tapes

[@Graham_Wideman]

@@Belginator Your comment does not appear to be comprehensible in English.

[@Belginator]

They plough feeders, do a little research before rubbishing people

[@Graham_Wideman]

@@Belginator I'm not rubbishing anyone, I was just pointing out that your sentence didn't make sense and maybe you'd like to rewrite it so we could understand what you're trying to communicate. Your new comment "they plough feeders" still doesn't make sense -- what does it mean to plough a feeder? That said, I did a search on "Mydata feeders plough", and I see that they have a "plough" (or plow) feature -- which is basically a blade or somesuch that peels the cover tape off the component tape to expose the parts. That's instead of relying on a take-up spool to pull the cover tape off, which requires peeling back a significant length of cover tape (and wasting the exposed components) when restarting a previously dismounted reel and setting up the take-up spool. I'm not sure how great that plow feature works out in practice, but it's almost certainly patented, so while interesting, is probably not immediately helpful for Stephen and co.

[@jstro-hobbytech]

I wish you all the best but the beanie and bangs with thr whole goblins and ghouls bs isn't gonna work when you become a corporate person removed from engineering.

[@SnazzzySniperTV]

R&D phase is always a pain in the ass

[@DAAI741]

That's the fun part

[@SnazzzySniperTV]

@@DAAI741 oh it is 😂 but when you spend 2 weeks on an issue which is easy to solve, you just feel like a regard after 😂