PnP – Designing my own Feeder

Having build BambooFeeder, BingFeeder and looked into PhotonFeeder I decided to design my own partly to solve issues I observed, partly to save space and partly to save cost! This was a proof of concept experience and it turned out very good. The 3D model of the 8mm Feeder is shown below. It is not 100% complete as I will need several rounds with printing, adjusting & testing, but results look promissing so far. I seldom show the full FreeCAD app, but in this case I do so for a reason.

Specification

  • 12 mm wide for 8mm tape.
  • Smart Feeder with intelligence/memory
  • Automatic configuration.
  • ESD/EMI safe.
  • 130 by 101mm – very small by accident.
  • Low cost – ca 10.- USD per feeder + control system.
  • Mounted on 2 x 2020 or 2040 frames.

Cost

  • Plastic PETG print ca 2.- USD
  • 2 x N10 motors ca 5.- USD
  • Bearings and screws ca 3.- USD
  • Control system – TBD

Reference to parts and where to get them will be given on github later.

To hell and back with FreeCAD

I use FreeCAD because it is the only open source CAD system I know. This is not a complex model IMO, but using FreeCAD 1.0 I started getting problems as the model became a slug on a i7 Windows10 with 16Gb RAM. At one point I got a “out of ram” message as I tried to save and even small changes took close to 10 minutes to execute. Imagine sitting and entering a single parameter and waiting 5-10 minutes to see the effect? That was me 2 days ago and I basically decided to to remove FreeCAD from my computer as useless, sluggish, junk! The model was 605Mb on disk (WTF?) and took some 12Gb in RAM. It was no way I could continue with that, but a friend urged me to test FreeCAD 1.1 and I did.

Loading with FreeCAD 1.1 and saving again the model shrinked from 605Mb to 62Mb on disk and “only” used 3,7Gb RAM – the difference allowed me to continue and finish the model. It is still slow to work with, but 5 sec waiting is nothing compared to 5 minutes. FreeCAD 1.1 is a big improvement over the earlier versions. Well done to those working on this release. Since the feeder model is in FreeCAD it also means it will be available open source.

Sprocket & Tape Feeding

I use a plastic sprocket with encoder holes and merged that with a gear. My first test was to 3D print this and it did to my surprice come out nice and strong. The sprocket (red gear on drawing) is only 1mm thick, but I could not break those tags with my hands so I think they will do ok. Early testing of tape feeding is very promissing. Using plastic gears is a big cost saver, and my take is that if I need to swap them out after some time, so what – they are still dead cheap to print in PETG.

Wormgear

I use two workmears on N20 motors and those are complex to 3D print. I have the option to change to brass versions, but that cost ca 2.- USD each. For now I want to stick with PETG and see how it goes.

Sprocket Decoder

I use IR decoders to read the sprocket position, but I could not find any pre-made sensor fitting, so I decided to use two 0603 components and make my own PCB’s forming a very narrow sensor around the sprocket wheel (Yellow parts at right) and I also made a cable gate from right to left to avoid that sensor cables got close to motor/gears.

Wheel Bearings

One of the decitions I made was that I wantet proper wheel bearings on every gear. They only cost ca 10.- cent, so 5 bearings is a total of 0,5.- USD. Well spent money in my book. With bearings also comes special screws that probably is another 1.- USD in total.

Peeler Mechanism

The peeler mechanism is the 2nd N20 motor (top left) with 2 gears to drag the tape between them exiting it at left and a classic end-switch to verify if tape is tight. I have no idea if this will work as the tape is thin and slippy, but we will see.

Control System

To operate the feeder I need a small control system and this is currently the green plate located at left. The control system fold into the lid so that it also is the wires from left to right over the tape track. That saved me from having wires on the sides. This drawing still lack the proper PCB with mounting holes, but PCB is fixed to the main part and lid will have a hole for it. I can also increase the size of the control system as it needs to hold a MCU, two H-bridges and CAN. MCU will be STM32H503 because I get those as low as 1,5 USD. They are a complete overkill for this task, but they have 128Kb Flash. I started coding on a smaller 32Kb MCU costing 1.- USD, but was in fear of running out of flash. I also use H5 for everything else due to cost/performance so it makes sence. I will return to control system design later.

Issolated communication

I will be using CAN with 3,7KV isolation on the control system. The reasons is that it only cost ca 2.- USD extra and with 50 to 100 Feeders on a machine I will be operating 100 to 200 DC motors and lot of wires with ESD/EMI challenges. One Feeder is not a problem, but 50 to 100 of them is a large system to destroy, so I preffer to do it properly!

CAN can operate 1 – 32 nodes easely so I need a USB/Ethernet/CAN GW capable of Ethernet (USB) and multiple CAN networks – and guess what – I accidentally have that ready as other articles describes ECU with multiple IO capabilities – CAN and Ethernet is on the list, but so is also RS485 and GPIO pins so I can easely create an advanced automation machine and integrate a mix of BambooFeeders, BingFeeders, T-2, Photon as well as my own.

That said I would like to think about that a bit because while my ECU’s are perfect for this task they also come with a cost… I can however accept a single cost in ca 200.- USD region if that enable low cost, intelligent feeders.

Intelligent Feeder – what is it?

Firsly I want to put persistent memory on the feeder, so that once you mount a reel you also configure the feeder. And once you put that in the machine OpenPnP will automatically recognise that you have 10K 0402 (example) in position xxx. Minimum config work needed. The next job is then for OpenPnP to execute auto-calibration and start running.

But, it is more – as we start/stop motors we send PWM pulses and the “normal” way is to start fast and break hard creating small “bumps” in the feeder – I want soft start and soft stop to avoid those twitches. I have a IR sensor for position, but the reality is that this is inaccurate so I want to use software average to make it more accurate by predicting timing of next position and adjusting. Once I have run adry run I should have data to compute this more accurate.

I have the option to add a 2nd IR sensor directly on the tape itself – I am still considering if this is worth it.

A last option is wherever I need a “break” on the tape itself. I have an option ready, but I have so far decided against it. The tape follows the track perfectly and is very tight (not to tight), but this is one thing I need to test and adjust.

Since we have memory we can as well count components on the reels.

I will add a vibration sensor on the dev kits for my own usage, but they will not be on the final product.

Noise/Vibrations

This is work in progress, but as soon as I start a N20 motor on a Bing Feeder I notice that sound and vibration is amplified through the plastic. I will have the same challenge, so I need to deal with that. I have an idea to isolate the motors, but lets see. This is the reason I want a vibration sensor on the feeder for testing.

To be continued…

I have so far only drafted a proof of concept on a new, small, low cost feeder. I have yet to set it into system and link it up with OpenPnP.

This is an open source project so I will put it on github later.

 

PnP – Feeder comparison

I finally got around to actually build a Bing Feeder using white PETG. I have bought 3Kg of Green PETG for later as I believe that color is better for camera support. Going from BambooFeeder to BingFeeder is a big jump – two completely different feeders and separate set of pros & cons. I will tempt to go through some of my observations.

Bamboo Feeder AS2:

  • No control system so you need to add a servo controller and deal with inrush current as these servoes draw 0.8A as the start.
  • Simple, low cost design (4 .- USD) – based on youtube movies very ok with some added camera usage.
  • 12mm wide on 8mm tape version, can be mounted tight.
  • Push-Pull with a cheam servo.

Bing Feeder v3:

  • Adds a control system to drive motors, communication is through two GPIO pins – on/off and pulse. You feed by sending a 10ms pulse. Closed loop where motor start and move until the IR sensor detect a gap, so it move 2 or 4 mm depending on what sprocket you insert.
  • Sprocket based so will drag the tape 2 or 4mm. Uses 2 x DC motors (1 c N20 and 1 x N39),
  • IR sensor to detect movement of sprocket wheel.
  • 20mm wide on 8mm tape.
  • Support 0402 by design.
  • Cost ca 20,. USD.
  • Far more dificult to 3D print.

My first observation on Bing Feeder is that I could have redesigned it to be 12mm wide. I also could have decreased cost and upgraded the control system to be intelligent. The question is if it is worth it? The reality is that if BambooFeeders costing 4.- USD works with Camera = problem solved. I ordered 6 x 8mm Bing feeders with 0402 support and from what I see they should manage 0402 and maybe 0201 – lets see then I start the machine.

Seen from my perspective these are both very interesting designs.

As I rebuild the PnP frame I will have a 600 x 600 x 600 mm metal box and be able to add Feeders on 3 sides, so for testing I will add both Bamboo, Bing and T-2 to see what I get out of them.

 

 

PnP – Smart Feeder

Looking at Feeders I looked into PandaPlacer’s BambooFeeder, microsmt’s Bing Feeder as well as the T-2 Feeder. I am not able to use any of these “as is” because they are not truly open source – but BambooFeeder is very low cost < 5.- USD and I had their 3D images so I could print them. I have received a T-2 Feeder with documentation and I am waiting on a Bing Feeder, but lets start with the BambooFeeder.

First – lets discuss why I do not use LumenPnP design anymore. This is the machine I started building, but I realized the machine was a bad piece of engineering “as is”. V4 is better, but it is too much plastic and issues that create instability on the magchine. microsmt and PandaPlacer did not exist then I started and these machines are all metall for a reason. So I ditch the LumenPnP mechanical design and copy the two others. Photon Feeders look great, but they cost 95.- USD and I need ca 100 Feeders – if I was to pay 95.- USD per feeder I could as well just buy 2nd hand Siemens or Yamaha feeders.

I have not been able to look into Bing Feeder design yet as I am still waiting. But, I started printing BambooFeeder and decided that this wa a candidate for upgrade because I need a lot of low cost feeders for 0603 and larger components. I do see that Bing and Bamboo both talk about 0402 and even 0201 components, but lets start with 0603. My challenge is that I need a lot of feeders and a control system for them and I can’t buy the later as is + I don’t want to either. 100 BambooFeeders in a system have a serious issue – each servo have an inrush current of 0.8A and a stall current of 2-3A – so as you switch on 100 servo based feeders my powersupply wiould need 80A – and yes I was offered a 5V/150A PSU from a friend, but lets not go there.

A better solution is to create a servo controller that also can switch on power one feeder at the time so that we can start feeders in sequence and avoid the insane inrush current. And since BambooFeeder have an open space of 20 x 50mm it become attractive to put a RS485 based Feeder Controller here – A MOSFET to handle 4A cost 0.1 USD, MCU with EEPROM 1.- USD so BambooFeeder is dead easy to convert to a smart feeder. A small MCU can switch on power to servo as well as run the PWM + measure current usage and if we have an Eeprom it can also be smart and remember what is on the tape – type of component and how many left etc – that’s a lot of extra functionality for 2-3.- USD and it gives me a smart feeder costing < 10.- USD in total.

If you only want 1-32 Feeders you can control these directly from a USB/RS485 converter and with a PSU budget on lets say 4A – the trick is to only operate one feeder at the time and start them in sequence. For 100 Feeders I need a GW Hub, but that is something I already have. I plan to use Duet3 as main control system, Raspberry PI 5 as main computer and a self-made ECU (Ethernet based) to control feeders and other things. If you have followed this channel you know that my ECU is a minimized PLC so I have the system to add whatever I want.

For MCU on the Feeder I decided on STM32L031 that comes with 32K Flash, 8Kb SRAM and 1Kb EEPROM + it cost ca 1.- USD per MCU in quantity of 100. Assuming I can get the code I want on this – if not I can try an old AVR -8 bit and ordinary Arduino IDE, but as a backup I can also scale up to a 3.- USD solution that include a STM32H503 – but lets see how coding goes.

On RS485 I just use a non-isolated traceiver because I will be isolated in the other end. This means I accept the risk that a hard spike might knock out a network of 4, 8 or 16 Feeders for now.

The Power part is a 3.3V regulator and a small MOSFET that is driven by a 3.3V signal. The servo signal itself is a 3.3V PWM,

MCU on the system is a bit tricky, but I can easely provide 5V/4-6A isolated – with 100 Servoes or DC Motors on a system we need to avoid a disaster if we get a motor spike, so we need to have sufficient isolation or you will suddenly find the entire electronics dead one day – been there, don’t want to go there again and isolation is cheap these days – lets do this properly.

As for T-2 Feeders – I like them and I have one with documentation, but they require a different connection system. For now I can connect one with a vero board as 4p rail and as this is RS485 as well we can connect them in parallell with BambooFeeders for testing.

As for Bing Feeders I have not looked into these yet, but I plan to connect a few of these as well if practical. All three feeders are usable for 0603, but have accuracy issues for 0402 and 0201, so I want to test and learn + I want to enable control systems/ecostructure for all three as open source. What I do on feeders will be open source under MIT license + I will offer to sell the control boards later – but, I hope someone else will produce a 2-3.- USD version on Aliexpress.

Taking a little about 0603, 0402, 0201 and why 0402 and lower become an issue. The hard reality is that the overall quality of these machines make even 0603 an issue as inaccurate feeders miss, have to use camera and retries. On 0402 and 0201 this become a larger problem as 0402 need 0.1mm accuracy on position and 0201 needs 0.05mm – a 3D print has an accuracy of 0.4mm so feeding a tape with 2mm +/- 0.05 mm becomes an issue. It will work on a good day, but you will experience that the machine miss even on 0603, miss more on 0402 and is unreliable on 0201. To compensate for this we need more accurate mechanics and no plastic Feeder will provide that – if you tune in a 0201 tape it will work for 2-3 picks and start missing. So what do we do?

We can buy more expensive Feeders like Siemens or Yamaha 2nd hand (or new) – they are metall and designed for 0201, but you also have to improve the rest of the system + your DIY machine suddenly starts to cost a lot of money. The alternative that I hope to achieve is to improve camera systems so they can correct errors – if we miss on a pick we simply use camera to auto-caliber next pick position etc. This will require far better cameras that will be slower to work with + better lights, but my take on this is that I want 0201 components and I don’t care if my machine need to use a bit of time – evrything is better than me sitting 3-4 days assembling a board by hand. For production in larger quantities I use different solution that become available with volum.

New PnP Head Mounted

New PnP Head. It is the same old LumenPnP Head, but I modified it to use laser sensors on both side + Nema8 steppers. The rest of the machine is in 3D print behind me, so give me a few days and I will share pictures of the assembly. I do not have access to original LumenPnP parts so I have to design around parts like custom switches. I also prefer the smaller Nema8 rather than Nema11 – but, lets see how it works out.

If anyone wants a copy of the design odifications just drop me an email.

 

Happy Easter

Just a picture showing what I am working on. I also think this is the first picture with Ethernet mounted. Both these boards will soon come in new versions.

I need to experiment a bit with picture resolution since my screens now are 4K – I used to reduce pic resolution by copying pictures through a 2K screen to make them more user friendly – that don’t work anymore.

The main board at right was made 2cm short of full length to enable 5 x DSUB9 in front panel with 1:1 cable to the ports. What you see here is a test cable used to communicate port to port. Firstly I detected that port 2 on the cable was not properly connected and secondly I detected that the 3rd port had crossed tx/rx – but, I got the CANFD ports working. Using CAN ot RS485 I usually either use DSUB9 or simply screw terminals. M12-5 and NEMA2000 (left) add a different perspective. I am quite eager to test both NEMA2000 and an increased speed version to see what speed/distances that can be used.

But, that’s work for another day. I lost power in my house yesterday and realized the reason was that a plug-board in the basement had short-cutted. The reason it shorted had something to do with 20cm rainwater on the floor. It has been raining so much that water now comes in through the floor rather than leaving out – so water pumps was installed this morning. Only minimal damage done, but this scare me a bit – I did not thing this was possible and have even bragged about my basement beeing dry – I never considered the water to come in from the drains in the floor. Oh easter fun!

ECU Design

The block diagram below reprecent a single ECU Node – which in reality is a baby with many names. It is also called a VCU (Vehicle Control Unit) or Mini PLC if you like, I prefer the terminology “ECU” – Electronic Control Unit since it is assembled in a waterproof, small box and general purpose.

We have several main board versions, but the latest dual ethernet version will become standard because it is more flexible than the previous versions. I started with a main board with 3 add-on modules and 3 CAN ports, but moved on to a pure M12 based, waterproof version with 8 add-on modules and have now extended that to include a dual Ethernet design. The key here is that the same board can be assembled with or without Ethernet if you want the IO slots for other purposes, but it made a lot of sence to have the capability to daisy chain Ethernet and avoid an external switch. Below is a picture of the M12 PCB’s and modules mounted in the lid to form 6 x M12 ports and one MX23 in this example. The advantage with M12 and MX23 is that they are water-/air-tight.

The new version with RJ45’s will not be directly waterproof, but it can be configured to use only MX23 or M12 connectors if we drop the dual Ethernet RJ45’s. I also have single port Ethernet for M12-4. but that target sensors that need Ethernet and not a daisy chain between nodes. I will do a few mechanical tricks to keep RJ45 waterproof – or more important airtight. As you close a box you will have a minimum of air that contain humidity inside. What you cannot afford is that this air is renewed bringing more humidity into the box + as this is to be used on vehickes and boats it must tolerate a dash of water as well.

Back to the block diagram you see 8 sub-modules – in reality the main board support ten, but as one position is needed for Power we max have 7 free positions (5 if we use dual Ethernet). The idea is that you use a distributed design with either CAN or Ethernet as network between nodes. And from any node you will see the system as a big tree of IO and logic. The sub modules use a 8Mhz full duplex serial port and the MCU frequencies 500 and 250Mhz is selected for optimal baudrate settings. I will return to the easyIPC protocol in use. A trick is that the sub-modules are booted and powered from the main board and can be switched on/off separately.

Configuration is mainly done with a CLI that can access the entire system from a script. Putty can be used, but we will create a specialized tool to support fw download and scripting.

Wifi/Lora/LTE modules will be added for wireless solutions, but these needs to be handed specially due to the antenna. I am in general not found of radio involved in control systems so the core design is wired and closed. IoT Cloud and Web technology can easely be supported, but outside the core control system. Web based systems are so slow and unreliable that they don’t notice a few ms extra through a GW dedicated for that purpose.

Support for screens are coming. I started with 7″ or 10″ screens and go up to 24″. I will get back to the details here, but in gereral we connect either CAN or Ethernet to a HMI controller so we can add as many screens or HMI nodes as we need.

At precent things are a bit in “SW mode” – meaning SW is beeing created and as this takes time it is not that often I have news to update here. It is easier to share pictures of HW than of SW 🙂

 

ECU – Dual Ethernet Main

Work in Progress – managed to finish schematics and place components – a bit more than I expected, but extended board on right side with 2cm so it goes wall-to wall in the box and SD-Card comes out as awell. Using KSZ8863RLL to achieve dual Ethernet on this. The MCU will see this as a RMII interface and it will act as a switch. This is a first draft as I have to go through the schematics again and document each component and optimize the layout a bit. But, it looks good. I use 2 x single RJ45’s so I can decide to populate with either none, one or two Ethernet on the same board. RJ45’s, SD Card and USB is not really waterproof “as is”, so might need to do something on the lid side on these.

  • 1 x STM32H723Vx – 512Kb Flash, 560Kb SRAM ticking at 500Mhz.
  • SWD Connector
  • 1 x USB
  • 1 x CANFD
  • 2 x 10/100Mbps Ethernet
  • 10 x Module connectors
  • 1 x SPI Flash
  • 4 leds

This board is still a bit work.

Simple CLI (Shell) Language

The ECU’s I make all have a small CLI included to execute a selection of commands including set/get commands accessing the dictionary. This started as a proprietary addition on 3 x CAN Hub, but is beeing upgraded to become standard on all as a minimal shell language. It is actually three modules involved as I have CLI, CLIParser and Dictionary. The initial scope was debugging, but I soon realized that this was a great way to do config as well. Below is a list of commands currently supported.

set <variable> <value>

Variable syntax is name of variable as listed in dictionary. tables use table[index].column format. Modules add another module[n]. in front so if you want to access variable x in table y on module 1 that is “module[1].y[n].x“.

get <variable>

See “set” for <vaiable> syntax. Will print the value of the variable on the console.

list

Will list all variables available.

reboot

Reboot system.

stats on/off

Will start or stop statistics.

module n on/off

Switch on/off selecte module.

help

Will display list of commands.

debug …. on/off

Switch debug prints on/off.

save/load …

Save/load config

download …

download new firmware- TBD

Other commands exist and will be added in time, but the majority of work is the set/get commands. This needs to be kept at a minimum. One candidate is file system commands to access flash and SD card, but I need to think about that. One option is to implement a reduced Linux syntax. I will need to use a few #ifdef’s so that I can start with a bare minimu (set/get etc) and extend based on available space.

RTOS w/Dictionary

RTOS with a Dictionary is standard in any system I build.

Most people will think FreeRTOS or a similar thread shifter then we say “RTOS” on embedded, but the hard reality is that most embedded systems are “barebone” and run some version of a round robin scheduler. Myself I do the same – I install FreeRTOS if I need to, but I still run a Linear Scheduler on top of FreeRTOS, Linux or Windows because they scale better than needing a stack for every thread.

Another major issue is that a linear scheduler can switch tasks with ca 10us in between, while any task shifter struggle with the same since they are depending in interrupts. You are welcome to try interrupts 10,000 times a sec (100us) and see what happens. You will be using a lot of CPU power on that interrupt alone – depending on MCU.

But, what about the OS part of any RTOS? An OS is more that just multi-tasking – it is your eco-system with library functions you can safely access in any module and expect to exist on any system you use.

  • Clock – RTC and ETC is a must
  • Signals and Timers
  • Message Queues
  • Standard API functions/framework.

Myself I also include a mechanism called a Dictionary that is an index over variables and tables that I use as API between modules. In a well designed system my dictionary will be the only module that can access all parts of a system and it consist of a generic part that is extended with an index table containing pointers to variables and tables I want to access.

One of the standard functions are Persistent Memory that is handled by the Dictionary.

Another critical function is entity integrity then dealing with protocols like CAN and Modbus. These protocols are capable of sending you a single parameter in a message, meaning that your system can start operating on incomplete data unless you have a mechanism ensuring integrity over a set of variables. The most used technique is a low cost CRC.

But mentioning CAN, Modbus and other protocols they all access the same variables making it very convenient to build these protocols on top of a dictionary.

Or to make it simple – a well designed dictionary will simplify your system dramatically and reduce the total usage of flash/ram if you have a complex system.

CLI and Configuration is another feature. Will all API variables accessible through a central dictionary it becomes ease to implement a CLI with set/get functions, and since CLI is USB/TCP or serial ports they can be scripted as well.

The last trick I often use is the HMI that mirror the dictionary on a PC that again is linked 1:1 with components or entities on the screen. This allows me to focus on gadgets and with a few lines of code I have fancy UI that can visualize or edit variables/tables on multiple embedded devices.

FreeRTOS or any thread shifter can be added with a few lines of code if I need them, most often I don’t.

As for modules I have a strict requirement that any module – collection of embedded C++ code – can be dropped into any project with only 2-3 lines of code since they use a standard API and OS definition that I can duplicate on any system embedded, Linux or Windows.

Added functionality like Redundancy or distributed systems is basically added dictionary functionality.

One advice is to use #ifdef to exclude/include entire modules. GCC is very good at excluding code that is not used, but this is the only time I recommend #ifdef and a custom config.h that manage this.

 

ECU – Dual Ethernet

I am using KSZ8863RLL to achieve dual Ethernet, This is a 3 port switch and it basically just replace the LAN8742. The MCU will just see an ordinary Ethernet not realizing that it is a switch. My initial idea was to re-use the ECU main board with minimal changes, but I underestimated the amout of extra components needed + many of the pins need a strap since they have one purpose during boot and another during operation. The result is that with 0603 components I run out of space, I can start pushing trancient caps to the back side, but I also have 2 cm space left on the right side so I can push the MCU to right and re-route the entire board. What I can’t move is the M connectors because they are aligned with the sub-boards, but I can move MCU w/components and route more to the right to free space for dual Ethernet.

The schematics on this is not 100% yet – I have found 2 good references that I am using, but it is a fiddle then you want to reduce components. I am using a trick to strap Ethernet to RESET as it power up so that it don’t boot before the MCU wants it to. I will also use a 2nd 3.3V PSU that can be switched on/off for this. I preffer to leave all components on top layer, but I will consider putting straps and trancient caps on the bottom. It is an interesting routing experimen, so will be interesting to see if I get this working. TBH the complexity on this is at the level where I expect I will need two PCB runs – actually I always do.