Tag Archives: diy

DIY pick and place machine

Current status of my DIY pick and place machine

Current status of my DIY pick and place machine

When I started developing the RasPiComm Plus I soon realized that I need the ability to manufacture smaller batches of our boards since we will have at least 10 different extension boards. I also wanted to stick to my 100% made in the EU principle.

Usually I would use my manual pick and place system to assemble prototypes. The boards are manufactured in Germany and sent to us. For larger quantities I would send the parts and boards to another company in Germany and let them assemble them. That costs almost €4.000 per 1.000 boards just for the assembling in the case of the RasPiComm. And it will take time, up to 4 weeks depending on their schedule. I needed a better solution and faster turnaround.

no more manual pick and place

no more manual pick and place

Since I have a manual stencil printer and a really cool vapor phase soldering oven a pick and place machine is the missing piece of equipment to have a reasonable low volume production facility.

So those were my options:

Buy a new pick and place machine

I compared prices of various options. An US company sells a cheap pick and place, very simplistic design (no housing, aluminum profiles), for about $25.000. Shipping to Austria would have added another $2.500. The machine itself was not impressive at all. I had my doubts if it could handle 0402 relieably.

The TM220A, a $4.000 toy-grade pick and place as Dave L. Jones calls it (and I am completely with him on that) has no vision. And it does not even look like it is worth $4.000. Not an option at all.

Buy a used pick and place machine

Tempting. Ryan O’Hara bought a Quad PnP for about $16.500 (without the feeders). He talked about it on The AmpHour. It is not that easy if you are not living in the States. I cannot come over and have a look if this machine is what I want and shipping is of course awfully expensive to Austria. Another thing is the software. This price only applies to the DOS version. I like having control over the software and my processes.

Build one

Well this option has the bonus that I’d have to build something from scratch. Do you need more reasons apart from this one? I know, me neither.
Nevertheless it has to be clear that building such a machine is inevitably more expensive than buying one in the short-run. If you don’t consider your time worthless of course. But one gets better with each project, you will learn a lot and you will have a system which you understand down to the tiniest bit of wire and code, so you can tackle every problem that arises, you can adapt software and hardware to your needs. And as an entrepreneur I also keep in mind that it maybe will be a product someday, or parts of it, so I always consider these kind of projects as an investment for the future not only in terms of learning and training for me and my employees but also having working modules that can be reused later on.

Scope

I thought about my goals, what I needed and what I don’t need. First of all this should be a rapid prototyping project. I will make design decisions based on if they are practical and the effort/benefit ratio fits for me. It should not be a project which is never really usable. Since this is more a side project that  a full-time project I gave myself 3 months. As I am writing this the 3 months are not over yet, so it is still in time.

I also did not want to think about automatic feeders too much for now. I knew I’ll have to redesign small areas of the machine for automatic feeder support. Until then working with belts held down by a polycarbonate shield should be sufficient for prototype quantities. For the small volume production target feeders are a must of course. So this is a compromise I make when starting this project – in the beginning I won’t have automatic feeders.

Hardware

After some hours of 3d-modelling we milled the first aluminum parts and ordered some off-the-shelf components and aluminum profiles. Milling was done with a very simple and cheap CNC, not even my good one (I got two of them). The CNC does not have a toolchanger, not even ball screw bearings. But it does its job. After that the parts went to anodization. Black of course.

Next step: Motors. I used quite beefy stepper motors in closed-loop mode for the X and Y axis and servos for the 2 heads I planned. Part rotation is again done by a stepper motor with a hollow shaft. Two simple turning parts made from stainless steel made the pickup base for the nozzle. I glued a magnet to the bottom. I used simple fuse clips as the nozzle holders. Nozzle-changer: done.

X and Y have ball-screw bearings with a pitch of 20mm to get the speed up. With a 500 step encoder with quadrature encoding this means a positioning precision of +/- 0.09° which would be  +/- 100µm. Enough for this machine. I plan to switch to BLDCs for a couple of other reasons with a 4000 step encoder which would lower that to 50µm in normal mode and 12.5µm with quadrature encoding. This is of course hypothetical, the mechanics are not that precise but still very good since I only used high quality ball bearings for X, Y and Z axis. The guides are also precision ones.

Assembing was easy, it took a couple of hours. Wiring was a bit of a pain, it took a whole day.

For the vision system I am using are 2560×1680 pixel USB3.0 cameras. One from the bottom for part alignment and a top camera for PCB/feeder alignment. I made a simple ringlight with 48 650nm wavelength LEDs. Funny detail: I was not able to do a circular pattern alignment of the LEDs in Altium, so I wrote a tiny Autohotkey script which allowed me to enter a number of parts and a diameter and it automatically aligned the parts correctly. Huge timesaver when you want to play around with the radius in which the parts are aligned on the PCB.

I also added a joystick to move around in the x-y plane, for testing and basic board adjustment. Fiducial recognition and board alignment should be done by camera of course, but to give the software a hint where the board is the joystick allows to move to the approximate position.

I wanted to have the top metal platform made since my CNC is too small to mill it so I asked a company what it would cost to do it for me. The price was about €1.500, too expensive for now. Thats why currently I only mounted a 10mm thick and 200mm wide aluminum sheet I had. Enough to hold my small PCBs and a couple of smd parts.

Software

Pick and Place Software

Pick and Place Software

Since I already did write some code some years ago for a pick and place thing I had something to start from. Writing a gerber-file importer took me two days (I did it from scratch using the gerber file format specification from Ucamco). Martin adapted the old code and added the support for our motor drivers, our cameras as well as reading the pick and place csv files. So we had our complete software solution to load gerber and pick and place data and control our motors. Sweet!

For the vision I used OpenCV which I knew a bit. This was very straight forward, it took me under an hour to get a usable rectangle detection on an 0402 part with the rotation information. Still have to test how it will work in the real world. If I learnt anything from building machines than that in the production environment not a single thing will be as in your lab/test environment. I set the filters so that only the red light of my ringlight is captured. That way sunlight won’t screw up my detection. We have a glass roof in the office and no housing for the pick and place yet, so that was quite a good test for the relieability of the alignment algorithm.

Another cool thing when writing your own software is that it can be taylored to your specific process. Since I use GIT as my version control system (even for Altium) I want the pick and place machine to pull the project and load the PnP and gerber data. The PnP will of course have a wireless lan built in and a nice sweet touchscreen and nice GUI.

On what hardware should the software run? Raspberry Pi?

The PnP could be controlled with a Raspberry Pi with our RasPiComm+ and in the beginning I wanted to use this as a platform. But since our old software is built with WPF (windows presentation foundation, a very powerful GUI framework), porting the GUI would have been too cumbersome. The bussiness logic would be easy to port since Mono runs on the Raspberry Pi. But in terms of GUI there is simply no match for WPF out there. And I want to use a touchscreen to control the PnP. Easy to make custom UI controls with WPF, very time consuming with other technologies. And when it comes to the vision system a little ARM processor would definately slow things down. The USB 3.0 cameras are running at 15fps at full resolution, pumping 180MB/s into the OpenCV algorithms, easy for a modern CPU but not realistic for an ARM processor (there is of course no USB 3.0 support limining bandwith even further). I also considered the Xilinx Zynq since I have a ZC702 development board. I played around a little bit, attached a camera but after a day I realized thats not the way to go. In terms of development time nothing can beat C#. And CPUs are fast enough for what I needed, and power efficency is not a mayor concern here. To be up and running fast I also would have needed extremly expensive Xilinx IP which I would avoid at all costs (no pun intended). And then there is the problem with fast adoptions. I want to be able to tweak and parametrize the vision system algorithms for different part classes, easy and fast when done in pure software, hard and time-consuming when done in FPGA logic even with all the amazing IP Xilinx provides.

So in the end it is a boring mini-itx board with a 3.2GHz quad-core and 4GB of RAM. More than enough, and alltogether (including CPU, RAM, SSD and full-HD touchscreen) cheaper than the ZC702 development board alone.

Automatic Feeders

The automatic feeders are not done yet, I just have some basic design approaches. Some say they are the hardest part. I don’t know yet, my focus was to get the PnP up and running. But if its too hard I will simply buy some. Currently I only have a simple aluminum board holding down the components with a polycarbonate sheet just for initial test run purposes. Simple but it works for now. I’m still a bit struggling with the resonance of the motors, at certain speeds small parts can flip. But on one hand the resonance can be minimized by tweaking the CL-parameters of the motor controller which I have not done yet , on the other hand I still want to design proper feeders and replace the stepper motors with BLDCs. So thats not a mayor concern for now.

Next steps

My next step is tuning the pick and place process and do a video. And building feeders of course.

Here is a short speed/motor test with a joystick (no actual pick and place action yet, I’ll do that in a separate video):

UPDATE: First pick and place test with and without vision:

Advertisements

RasPiComm v3 almost ready

RasPiComm v3 missing headers

RasPiComm v3 missing headers

I assembled RasPiComm v3 and it all works. This should be the design for production. Sadly the new connectors for the RS-485 and RS-232 ports still need 2 (!) more weeks to deliver, I ordered them 2 weeks ago. I only have the 2-pin pluggable power header yet, and only one half (the pluggable screw-terminal also takes another 2 weeks). So the picture to the right is still missing the pluggable headers, but you get the idea of the new design.

I had to make room for the new (big) pluggable headers, so the outputs are now on 2mm pitch headers (not polulated). SPI and input are also 2mm pitch headers and also not polulated. If you need the inputs, outputs or SPI you just need to solder the headers. I think most useres wont need them, and if you do it is easy to retrofit.

I2C Header

RasPiComm OLED

Raspberry Pi with RasPiComm OLED

I changed the I2C header from through-hole to SMD, simply because the battery holder is now below this header to avoid collision with the S2 header of the Raspberry Pi. This will probably be a male connector on the production board.

Production
I know, what you are really interested in is the availability. Well, I already got the quote for the first batch, way off my initial calculation, but they screwed up the material costs. They now have my BOM and I’m waiting for another quote. So I’m still on it and hoping that I can place the order in one or two weeks.

RasPiComm v3

I want to give you a short update about the RasPiComm progress. You’ll find the schematics of v3 below.

I reworked the whole board and rerouted it all. I tried to implement as much feature requests as I could while preserving the footprint.

I also decided to start working on a RasPiComm Plus board. It will be bigger and better! But it will not play in the same league pricewise.

But first things first, here are the changes I made:

  • Moved the backup battery out of the way. Now it does not collide with the DSI (S2) plug on the Raspberry Pi.
  • 5V tolerant inputs
  • pluggable terminals for power, RS232 and RS485
  • supressor diodes for the outputs. You can now directly connect relays to the outputs
  • output is now a pinheader. The RasPiComm focus is on serial communication. Sacrifice I had to made to get the pluggable terminal headers in.
  • Extra 2 pin header for 5V fan. In case you want active cooling on the Raspberry Pi
  • Changed the through-hole joystick to a SMD variant. That resolves a little issue with the aluminum capacitor of the Raspberry Pi. No need for a tape or PCB support below to prevent accidental joystick activation
  • Extra tantal capacitor for external 5V power supply through the power header
  • SPI header

Shipment: Since my first post about the RasPiComm about 1 week ago I got a lot of positive feedback, so I really want to push v3 to production soon. Please give me a little time for finding the right partner for that. Eben Upton (Director of the Raspberry Pi foundation) is helping me to get this to Element14 (Farnell), this would be my preferred partner. Thanks Eben for your support! But as they are very busy with the Gertboard right now I don’t know about the timeframe yet. So I am working on it!

And thank you all for all the nice comments on my first blogpost about this! You all keep this going!

Downloads (Creative Commons Attribution-ShareAlike License)

RaspiComm_v3_schematics

 

RasPiComm – Hardware

Thank you for all the views and responses on my original RasPiComm blogpost!

Here I want to explain the RasPiComm hardware. The software part will follow next week.
At the end of the post you will find the schematics of the RasPiComm version 1 and version 2.

If you are not interested in the RasPiComm hardware, take a look at the original RasPiComm blogpost!

Now, let’s start!

Version 1 vs. Version 2

RasPiComm version 1

RasPiComm version 1 with populated RS-485 driver

As I mentioned in the first blogpost about the RasPiComm, I did two versions of the board. The first version had either one serial port OR an RS-232 port. I used the /dev/ttyAMA0 (TX on GPIO header pin 8 and RX on pin 10. You could either solder the MAX3232 for RS-232 or the MAX3483 for the RS-485 port. But there was another disadvantage: I used the GPIO1 (pin 12 on the GPIO header) for switching between receive and send mode.
Just a short explanation why you need to switch between send and receive mode: Unlike RS-422, RS-485 is an unidirectional bus system. That means that you use the same wires for sending and receiving data, so you cannot send and receive at the same time. Usually you always stay in ‘receive’ mode. If you want to send data you switch to the send mode and return to receive mode immediately after sending your data. The timing is critical here, I will explain that later. There are chips out there which support “auto-direction” from Maxim. I have not yet worked with them, I’ll probably will have a look at them in the future.
Another thing that changed is that version 1 had a SPI header. I removed them simply because the wiring of the SPI tracks would not have been optimal (they are not optimal yet but way better this way).

Changing to RS-485 via SPI

RasPiComm to Rasberry Pi Connector

So the disadvantage of version 1 is obvious: You could either have RS-232 or RS-485, not both. There was another problem. Switching the GPIO line for changing between receive and transmit was suprisingly slow. Not exactly because the GPIO switching is too slow but because it is not so easy to find out when the last byte was transmitted completely to switch back from send mode to receive mode. You can check if the /dev/ttyAMA0 send-buffer is empty using tcdrain(). Sadly this function blocks too long, we lose valuable miliseconds after sending until we can switch to receive mode and receive data. That means that all data that is sent by a RS-485 client before switching back is lost.
To overcome this limitation, and the problem that I can only use either RS-232 or RS-485 I dropped the MAX3483 and used the MAX3140 in version 2. This chip has an SPI-UART and RS-485 controller in one chip.
The interrupt line of the MAX3140 is connected to GPIO0 (pin 11).

RS-232
The RS-232 connector is driven by a MAX3232, I will probably replace it with another, cheaper version for the production board. Only TX and RX are connected, sadly the Raspberry Pi does not bring both CTS and RTS to the GPIO header, so hardware handshake is not supported. But this is not used often anyways.

I2C Connector
If you look closely at the I2C connector in the schematics you will see that this are actually two I2C connectors. It is a 2×4 header, and unlike all other headers row 1 and row 2 are not identical. I did that for a simple practical reason. I use this header mainly to connect I2C displays. There are two common pin layouts:

  • 5V, GND, SDA and SCL
  • 5V, GND, SCL and SDA

So I did both of them. With that little trick you can connect both types directly to the board using either row 1 or row 2.

Inputs
All 5 inputs are pulled-down to GND. They are all 3.3V inputs with an 1k resistor to the Raspberry Pi.

Outputs
Both outputs are open-collector outputs and switched with a BC847 transistor.

Power connector (3.3V, GND, 5V)
The 5V line can be used to supply 5V if you do not use the USB plug or use it as 5V ouput if the Raspberry Pi is connected via USB.
The RasPiComm generates its own 3.3V from 5V, the 3.3V line is connected to this output (200mA combined maximum rating).

RTC with backup battery

RasPiComm bottom

RasPiComm bottom

The backup battery on the bottom side of the PCB is a CR2032 cell. It should power the DS1307 for approximately 10 years. Currently there is a small problem with the battery holder on the bottom – it collides with the S2 socket (DSI). The RasPiComm v2 still can be connected to the Pi, but you cannot push it all the way down (it’s only 1mm). For testing I removed the S2-connector from my Raspberry Pi board. For the production version the PCB will get 5mm wider (did it without changing PCB size!) the battery socket is moved out of the way. It won’t change the footprint of the Raspberry Pi, the 5mm go torwards the video connector. That also means that the battery is slightly moved over the processor. This should not raise any temperature problems, neither for heat dissipation nor for the battery since the operational temperature range for the CR2032 cell is -20 to + 70 degrees Celsius (-4°F to +158°F).

Downloads (Creative Commons Attribution-ShareAlike License)

RasPiComm v1 schematics

RasPiComm v1 schematics

RasPiComm v2 schematics

RasPiComm v2 schematics

RasPiComm – a Raspberry Pi piggyback board

Raspberry PI Communication and I/O board

RasPiComm on Raspberry Pi

Update: visit our forum on our freshly relaunched website amescon.com to comment or ask questions about the RasPiComm!

After finding out about the GPIO header of the Raspberry Pi it was inevitable to build some kind of extension board for it. I was working with Arduino, Netduino and FEZ Boards in the past and they all are quite expensive compared to their capabilities and not really stable, especially when it comes to Ethernet communication. The Raspberry Pi seemed to be a perfect alternative for complex applications and easy development. Of course it is an application processor not a microprocessor, so they are not quite comparable but nevertheless a great platform for a very decent price. I want to thank the Raspberry Pi team for bringing out this awsome piece of hardware!

After checking out the available documentation I built the first version of the extension board. Even though it was working as intended I wanted to get rid of some limitations so I built v2 which is slightly different. I will write a seperate blogpost about the technical details, here I just want to share the basic concept and capabilities.

Features

  • RS-485 port
  • RS-232 (‘serial’) port
  • 5 inputs connected to an onboard joystick and screw terminals
  • 2 outputs (5V) with LEDs (green and red) also connected to screw terminals
  • I2C connection
  • Real time clock (RTC) with backup battery

What for? RS-485! And why?

RasPiComm Connectors

The main reason I built the RasPiComm was the RS485 interface to control stepper motors. You can of course use I/Os in PWM mode and a second I/O for direction to drive this, but since the Raspberry Pi is not a realtime system it does not behave well especially with start/stop ramps. And you would have to write code that does all of that. But I like elegant solutions, and this is certainly not one. There are a lot of stepper motor controllers out there with rs485 support. I’m using the steprocker board (http://www.motioncontrol-community.org), a very powerful open-source solution with state-of-the-art stepper control. This board supports a 256 microstep resolution for ultra-smooth stepping. And it implements the TMCL protocol, which is very easy and fast. The neat thing about RS-485 is that you can control up to 256 devices. The steprocker board is capable of driving up to 3 motors. So if you want you can control 768 stepper motors with one Raspberry Pi. If you really want to.

RS-232
This is always nice to have. It simply connects to your “/dev/ttyAMA0” serial device to the outer world. It outputs the correct RS-232 levels so you can connect it directly to a PC serial port if you want. You can open a console and watch the debian debug output for example.

5 inputs
I added them because the GPIOs are there and I don’t like unconected I/Os. Who knows, someday I (or you?) will need them. The onboard joystick is handy for launching actions and to test your program.

2 outputs
The main reason for adding them were the LEDs. In version 1 these 2 outputs were only connected to two LEDs. In version 2 I added 2 transistors and they switch 5V. I added screw terminals, so if you want you can connect two relays (with a supressor diode).

I2C connection

RasPiComm with 128×64 pixel OLED display

The I2C connection is also connected to a header. I attached a small I2C OLED display. There are a number of cheap I2C displays on ebay.

Real time clock (RTC)
And last but not least: I attached a real time clock to the I2C bus. The Raspberry Pi does not come with a hardware clock. It forgets the time when it looses power. Its very well understandable that they did not do that, the RTC chips aren’t cheap. But nevertheless a clock is a nice thing to have, especially if you want to trigger actions based on the time of day (home automation for example).

I placed the battery on the backside of the board. Debian supports the chip I used directly, so there was no programming, it simply works with a few calls and your system time is synced with the hardware clock.

Piggyback board design
As I mentioned before, I like elegant solutions. And I also like compact solutions. So my goal was to create a small, elegant extension board without using a flat cable to connect to the Raspberry Pi, my desk already is cluttered enough. It should be a shape which does not change the footprint of the Raspberry Pi and doesn’t cover the processor to maintain heat dissipation. Ths ‘piggyback’ design was born. It doesn’t provide a lot of PCB-space, but there is still plenty of room to realize a couple of features if you go with smaller SMD parts. They are all still hand-placable since I only use tweezers to populate my prototype boards.

In part two I’ll cover the technical details and software.

If you have ideas how to improve the RasPiComm go ahead and post a comment. Want to see other features? Form factors? Colors?

RasPiComm Hardware
RasPiComm v3

%d bloggers like this: