Sunday, July 6, 2014

blueShift - An OpenXC LED Tachometer

An Arduino, some addressable LED's, a bluetooth module, code and a 3D printer come together to make blueShift - An OpenXC LED Tachometer.  blueShift is so named for the Bluetooth protocol used for data communication, and the use of a tachometer to indicate when to shift your car.  It may be amusing to note that the driver and passengers traveling in this car would observe Blueshift when peering thru the windscreen, provided their velocity was sufficient.

About a month ago I picked up a new car.  It's a Ford Fiesta with a 1 liter, turbo, eco-boost engine.  It achieves roughly 2.5 times greater fuel efficiency than my Jeep.  This fuel efficiency was my primary impetus to purchase, but the new tech in automotive electronics is a pretty cool bonus.

It took a couple days driving around to figure out all the bells, whistles, and electronic gizmos in the Fiesta, and just that quickly, I was looking for something more.  What that turned out to be was Ford's OpenXC API.  OpenXC is part hardware, part software.  It is open source, as the name suggests and aims to ease us into integrating vehicle data into our android apps, and in case of blueShift, embedded hardware.

Let's take a brief, but closer look at OpenXC and the potential it provides.  For quite some time now, auto manufacturers have provided an OnBoard Diagnostics port.  This OBD2 port, as it is sometimes called, is a digital interface to engine management parameters and chassis/body status.  To the typical hobbyist, an OBD2 ports data is relatively inaccessible.  You would need to know manufacturer proprietary PID's for the CAN messages you were viewing to discern "air intake temperature" from "outside air temperature" for instance.  Likely, the information you were able to decode is specific to one vehicle make/model or worse, ECM batch.

Under the OpenXC umbrella, Ford has developed a hardware module called a Vehicle Interface or VI.  This VI plugs into your OBD2 port, and interprets engine parameters and chassis/body info.  These data are then packaged into JSON format, and relayed out over Bluetooth SPP.  If you were to look at the OpenXC Data set you would discover that listening to this Bluetooth connection provides you with a plethora of vehicle specific information in real time.  For instance, you can read your accelerator pedal position, fuel level, odometer, brake pedal status, and of course engine speed.  The list goes on.

blueShift aims to utilize these engine speed data to drive a set of LED's in an easy to interpret, graphical manner.  The circular nature of an off-the-shelf LED strip lends itself to this project nicely.  What's more, these LED's are individually addressable, RGB LED's.  This means that we can set any LED on the ring to just about any color we like, at any time we like.  blueShift takes advantage of these addressable WS2812B LED's to create an interesting and informative display.

At first glance it may seem a second tachometer in my car is superfluous.  I can say after having used blueShift, quite the opposite is true.  The LED's are much easier to read with peripheral vision than the stock tachometer needle.  Likewise, blueShift would be very useful for someone who races Ford automobiles.  Additionally, blinky LED things are just plain cool, and no further justification for this project is therefore necessary.

The only wired connection to blueShift is for power.  All data transfer is accomplished over Bluetooth SPP.  Presently, this power is derived from my vehicles on-board USB power.  I have plans to derive power from the OpenXC VI power port in the future.  This will require a small regulator to convert the vehicle ~14 V DC to a microcontroller compatible, regulated 5 V DC supply.  This supply will also need to supply power for the LED ring, so current consumption should be considered.

3D Printed Enclosure:

Sometimes a project will take you to unanticipated places.  In the case of blueShift, that ended up being the land of 3D printing.  Typically when I make a new project I am left to drilling and milling existing enclosures, and sometimes tupperware.  What I am left with is a finished product that looks less than finished.  When I was envisioning how I wanted blueShift to look, it deviated rather drastically from the prototype seen below.

Once it was decided to build a 3D printer to print blueShift's housing, I started down the path of designing a 3D printer of my own.  I had a basic layout and construction method in mind when I started looking for approximate pricing on parts.  I soon discovered that the constituent parts of my 3D printer design were approaching the cost of a 3D printer kit.  This led me to purchase a Prusa i3v from Maker Farm, and I am glad I did.  Together with my girlfriend Miriam, we assembled the kit in a few evenings.  The decision to build a kit saved substantial time over designing a printer.  Our first prints were the requisite calibration cubes and then jewelry as seen below.  There is probably still some fiddling to do with the printer setup, but I am pretty pleased with the print quality so far.

Here is a photo of the partially finished 3D printer.

I designed the 3D models for blueShift in AutoCad 2014.  I then exported the models as *.stl files and uploaded them to Thingiverse for sharing.  You can download the *.stl files to print your your own blueShift enclosure, or I think companies like Shapeways may print them out for you if you don't have a printer ( yet ).  I have no experience with that.

Below are some photos of the enclosure in various states of printing, and drawing revisions.  The portions of the print that have large gaps and look like a lattice are intentional.  This makes up supporting structure for parts with overhangs while printing.  It is designed to break off easily, and in practice this is sometimes true.

I am really enjoying 3D printing.  Even with it's obvious limitations, I feel that I will make good use out of this tool.  I see many opportunities to print things that may or may not be necessary, but ultimately I am having a great time with it.


Part List:

  1. NeoPixel Ring w/ 24 WS2812 RGB LED
  2. Arduino Pro Mini
  3. BlueSMiRF Bluetooth Module
  4. NPN transistor + 1k0 base resistor
  5. Pushbutton Switch ( optional )
  6. FTDI cable for programming and power
  7. A Ford OpenXC VI

I am using an RN-42 Bluetooth module from Sparkfun called a BlueSMiRF .  One of the first things to do is connect to the modem and configure it for Auto-Connect Master Mode (SM,3).  The AT Command sheet will walk you thru this process.  For more detailed information on how to connect the Bluetooth module, and enter into command mode, refer to the Sparkfun tutorial.

With the Bluetooth module configured, we can wire up the rest of the circuit and tuck it into the blueShift housing.  Here are a few pictures that show this process.  Great care should be taken to avoid short circuits.  Currently I power the blueShift from an FTDI USB cable.

The little tactile switch will perform a function in future software revisions.  For now, it does nothing in software.

The two red wires with header pins are for the bluetooth modem power.  This is represented as a SPST switch on the schematic labeled "HEADER".  It is necessary to unpower the modem when uploading new firmware to the Arduino.  This should be shorted out while operating blueShift to power the Bluetooth Module, and disconnected for uploading new firmware to the arduino.

This would be a good time to install the software and verify everything works.  If you need to re-solder anything, it is better to find out now.  The author may have experience that lead to this warning.

In the picture below, this semi-opaque, 5mm thick disk is possibly polypropylene.  I purchased the stock from an unknown bin at a shop and belt sanded it into shape.  There are 3 equally spaced clearance holes drilled into this lens to accommodate the M3 mounting bolts which we are about to install.  Drop the lens into the outer housing and line up the holes.

Insert the assembled and tested inner housing into the outer.  Line the three M3 bolts up and screw the entire assembly together.

Screw the Ram Mount to the back of blueShift.  This will now suction cup to your windshield and plug the FTDI USB cable into a USB port in your car.  If you don't have a USB port onboard,  there are 12 volt outlet to USB adapters available.


You can download the Arduino code here.

When blueShift first turns on, there is a brief pause.  During this time, we are waiting for the Ford OpenXC VI to boot up, and for blueShift to establish a connection to the VI.  For a bit of fun, we display the "Waiting for Bluetooth Throbber" that you can see below.

Once a connection is established and valid RPM data is coming thru, the display changes to "Run Mode".  In this state, RPM is displayed as a green LED trail.  It grows clockwise as RPM increases, with the final LED being displayed in red for a bit of visual interest.

This final LED, the highest LED displayed, is "sticky".  That is to say, as your RPM begins to decay, the peak RPM read will continue to be displayed as a single red LED.  This will either persist until 3 seconds have elapsed since the peak measurement or once a positive rate RPM is detected.

Since OpenXC provides with boolean headlamp status on the same bluetooth connection, we can implement auto-dimming of blueShift.  As soon as your headlamps come on, blueShift will dim.  When your headlamps return to the off state, blueShift will regain full brightness.  This is not just a nicety - it is rather important.  These LED are quite bright and without dimming at night the result is a well lit car interior.

The sticky LED telltale can be seen in the video below.  You can also see the auto-dimming feature towards the end of the video.  It's a little hard to see when the headlights turn on because its still light out, but you can see blueShift get dimmer.  You can also hear the headlight knob click on.

At the time of this writing, blueShift is hard coded to a specific RPM span.  That is to say, if you wanted the first LED to light at 500 RPM and the final LED to light at 6000 RPM, you would need to reflash the firmware.  After I get a few more miles on my car I will want to change that so, I will probably use that tactile switch as a way to program the RPM span without reflashing firmware.

To implement this I think it would be good to have a "programming mode" where say you enter program mode and blueShift will keep track of the highest RPM read.  You press the button once to set this as the lower RPM span.  Now, rev your engine and blueShift will remember the highest RPM achieved.  Press the button to store this as the high RPM span.  These new values will be saved to EEPROM and recalled at the next power on cycle.

Additional firmware upgrades include moving to JSON parsing.  Right now I just read the full JSON line and manually parse the string for the values I want.  If something were to change in the VI firmware, it is possible to break my code.

Are you making a blueShift?  Send me a message, I would love to hear how it's going.  Happy making!

Monday, April 21, 2014

DIY Pick and Place Machine - Part 3

Be sure to check out the other posts in this series below.
Part 1
Part 2

Now we are starting to make some headway into making this stock ShapeOko kit into something resembling a CNC Pick and Place Machine.  I am quite pleased with the progress so far, and I am learning a lot along the way.  For instance, I have discovered that blunt tip dispensing needles with luer lock connections are non-concentric, but more on that later.  For now, let's talk about some of the parts that are making this PnP take shape; specifically the head unit and the PnP fixture.

Head Unit:

The purpose of the head unit on this PnP machine is to facilitate the following operations:
  1. Advance the component tape to present a new component for placement.
  2. Vacuum grip to pick up a component for placement.
  3. Rotate the picked up component to the correct orientation for placement on the PCB.
  4. Hold a syringe of solder paste for robotic solder paste dispensing.
When designing the head unit I wanted it to be made from primarily off the shelf parts.  This speeds up development and allows a distributed approach for duplication should any reader wish to replicate the same.  I was able to achieve this ideal save one part, which I turned on a lathe.  The rest of the parts for the head unit came from online retailers that are listed below.

Here are a few pictures of the head unit assembled.

Below is a photo of the head unit prior to assembly.  It is annotated with numbers which will correspond to a descriptive list.

Refer to the image above and the list below for part numbers &c.  I see now that I left off an annotation number for the bottle of loctite.  It is slightly optional, but probably a good idea for many of the fasteners as stepper motors can be a bit vibratey.  All of the parts ( except #9 ) came from the following vendors: McMaster-Carr, Servo City, SDP/SI, Clippard, and eBay.  

  1. A 10-32 threaded female luer lock adapter and blunt tip dispensing needle from McMaster Carr.  Respective P/N's: 51465k151 and 75165A682 and 75165A677
  2. 6-32 nuts.  I had these. They measure 0.245" across the flats.
  3. 6-32 x 3/8" Long,  Button Head Cap Screws.  I purchased these from a local hardware store.
  4. 6-32 x 1/4" Long, Button Head Cap Screws.  McMaster P/N: 98164a106
  5. #6 Washers.  McMaster P/N: 98032a436
  6. Wood Screws to hold the maple block ( #7 ) to the head.
  7. This is a v-cut block of wood for holding the solder paste syringe.
  8. A flat channel bracket from Servo City P/N: 585468 and a pair of Servo City 90 deg. dual mounts P/N: 585470.  All of this is held together with screws ( line item #4 ) and washers ( line item #5 ).
  9. I turned this shaft out of some 8 mm bar stock ordered from McMaster-Carr P/N: 1272t38  A drawing to make this part is below.
  10. A Clippard pneumatic cylinder, plus a hardware store washer.  This is for drag feeding the SMD tape.  Clippard P/N: FSR-05-1 1/2
  11. Two 1/4" I.D. bearing mounts from Servo City P/N: 535110
  12. 1" x 1" 80/20 Extrusion.  I cut mine slightly shorter ( < 3.75" ) than the Servo city bracket this is mounted to.
  13. 3.75" Aluminum channel from Servo City P/N: 585443
  14. GT2 Timing belt and 2 disparate pulleys from SDP-SI P/N: A6R51M093060, A6Z51M036DF0608, and A6Z51M036DF0605
  15. A NEMA 17 stepper from eBay, plus a stepper motor mount from Servo City P/N: 555152
  16. An arbor shim kit for setting the end play of the diameter 8 mm shaft ( line item #9 ).  McMaster P/N: 3088a928
In the assembled head unit photos you can also see a brass spool valve for diverting the CO2 flow betwixt the solder paste syringe or pneumatic cylinder.  I probably should have just ordered another solenoid, but the diverter valve is Clippard P/N: HTV-3F.

Lets begin assembling the head unit by attaching the aluminum channel from Servo City ( line item #13 ) to the 80/20 extrusion ( line item #13 ).  You will notice I used non-standard mounting methods here.  I drilled and tapped the 80/20 extrusion for 40-40 BHCS ( Button Head Cap Screws ).  This was necessary because the standard 1/4-20 BHCS plus t-slot nuts came too close to my pulleys and belt for my liking.  One way around this would be to select a smaller tooth number pulleys and belt, while maintaining the same center to center distance.  


Next up, attach the bottom bearing mount using some 6-32 x 3/8" BHCS's, washers and nuts as shown below.

Below, you can see the pneumatic cylinder installed.  Note the hole position, and don't forget to install the GT2 belt prior to continuing, otherwise you are likely to gain the authors experience in re-assembly.

In the next photo you can see the stepper motor installed with the stepper motor mount from Servo City.

Install the diameter 5 mm I.D. GT2 pulley on the stepper motor shaft.

Prepare the aluminum plate and brackets as shown.

And install the solder paste syringe holder using wood screws.  For this, I countersunk the aluminum plate so that the wood screw heads were below the surface.

Attach the solder paste syringe holder assembly to the front of the aluminum channel using 6-32 x 1/4" BHCS's as shown.  It is important to do this now, as it could affect the vertical clearance on the vacuum shaft.  The author was able to install qty 3, 6-32 screws during this operation before discovering the stepper motor was blocking one of the screw holes.  It was decided to move on with life instead of trying to increase the number of fasteners further.

Ok, the steps shown below are the most complicated, but I think you will manage to follow along just fine.  Temporarily install the vacuum shaft and top bearing mount.  You may elect to install this with one screw.  Slide the shaft axially to detect end float.  Measure, if you can, this displacement.  Mine was 0.015". Otherwise, you can attempt an iterative process of fitment.

Remove the top bearing plate, install the dia 8 mm I.D. GT2 pulley, and install one of the shims from the arbor shim kit.  Since I knew my end float was 0.015", I selected a 0.012" shim.  This would leave me with 0.003" clearance.

Bolt the top bearing mount in place, and check that the shaft rotates freely and there is minimal, but perceptible end float.  Mine was predictably measured to be 0.003" axial clearance after assembly.  If you cannot rotate the shaft, or cannot detect/measure end float, you should select a smaller shim and repeat.

Below you can see the luer lock adapter and blunt dispensing needle installed ( line item #1 ).

Here is the assembled head unit interfaced to the ShapeOko gantry via an 80/20 extrusion angle bracket.

Remember that spool valve I mentioned earlier?  here it is installed to the head unit with a Servo City P/N: 545424

This is where I discovered just how bent/curved/or otherwise not straight the vacuum needle was.  When I rotated the head unit with the stepper motor, the needle spun around and orbited too.  So, I bent the needle a little and was able to get it pretty concentric.  Then I removed the needle, and re-installed on the second start thread only to discover the needle was non-concentric again.  For now, I will continue with this setup, but it may be worth investigating some precision needles at some point - probably making them.

If you recall the shaft that needs to be fabricated, below you can find a drawing.  Basically the length of the diameter 8 mm shoulder is going to be determined by your particular setup.  As it is drawn below worked well for me, but you may do well to have a measure of your system first.

The PnP Fixture:

You have probably seen the aluminum plate with milled slots, clocking holes, a shoulder register and a bunch of tapped holes.  This is my vision for making a low volume, home pick and place machine.  I can make as many different plates as I need based on the circuit board I want to fabricate.  

The design is made pretty universal.  There are 4 tracks for resistors or transistors, two tracks for capacitors, one for a regulator and one for a mosfet.  I selected these parts and subsequently the track dimensions based on the boards I wanted to populate first.  If I have a new board design in the future, and this setup does not have tracks for the correct parts, I can make a new fixture.

Here is how I envision this fixture working.  I say envision, because I am still learning how to write G-Code, and I am not sure how to do what I want just yet.  At the time of this writing, I am currently working on the programming I am about to describe.

If you look at the fixture you will see two countersunk holes for flat head screws.  This fixture will be bolted to the ShapeOko MDF work surface here. 

Inboard and towards the front, you will see two round bores of different diameters.  They would have been the same size, but I messed one up while machining.  Since the fixture is unlikely to ever be bolted down, perfectly aligned with the machine coordinates, I am trying to do the following.  Probe each of these two holes, calculate the angle between the machine coordinate system and the line made by joining these two center points, and rotating a new set of coordinates for the machine to use that are aligned with this fixture.

There is an X-Y register for locating the circuit board.  This X-Y ( 0,0 ) is located 5.000" right and 0.500" toward the rear from the bottom left probe bore.  Using this new origin I know where my circuit board pads are ( from the gerber files ), and I also know where to tell the machine to look for each type of component to place.

To hold the circuit board in this register, orienting it's X-Y ( 0,0 ) I used a piece of an old coping saw blade.  Held in place on one end by a Jarrah wood clamp, the other end applies enough spring pressure to keep the board steady and registered during assembly. 

Things are starting to look like this might just work.  I still have a long way to go with G-Code and tuning the machine operations.  I haven't even fed any parts yet!  Never the less, I keep chipping away at the subcomponents on this job.  

Incidentally, I will probably be showing this machine off at the Ann Arbor Mini Maker Faire, so if you are in the area, be sure to stop by.

Tuesday, April 15, 2014

DIY Pick and Place Machine - Part 2

Be sure to check out the other posts in this series below.
Part 1
Part 3

Ok, so we are moving right along with this project.  Parts are coming in weekly, and other parts seem to be endlessly delayed, so we make do.  Since the last post I have been concentrating my CNC PnP education on the following areas:

  • Automagic Z-Axis probing for setting the machines vertical zero position relative to your PCB.
  • Wiring in an emergency stop.  This should have been done before starting the first time.
  • Configuring LinuxCNC's HAL for digital outputs.
  • Investigations into robotic solder dispensing.
Much of this work has been around the back of the machine, so here is a picture of that, and lets discuss.

Above is the back side of the machine.  Along the top is a piece of DIN Rail that extends from the left and right of the ShapeOko frame.  This is where the majority of parts are installed.  Below this, you see a grey vertical surface with parts mounted.  This is a long steel L-Bracket, surplus from some IKEA furniture, that I screwed to the ShapeOko MDF work surface.

Working ( approximately ) from left to right, here is a list of parts:
  1. Green parallel port breakout board.  This gives screw terminal access to your PC parallel port.  To this we attach stepper drivers, digital outputs, digital probe inputs etc. Phoenix Contact P/N: FLKM-D25.
  2. DIN Rail mount Terminal Block.  Multicomp P/N: SPC10564
  3. I colored some of the above terminal blocks red or black with a sharpie.  These are electrically connected with Mulitcomp P/N: SPC11891 jumpers
  4. Big Easy Stepper Drivers - sold by SparkFun P/N: ROB-11876
  5. The two yellow circles are 3-way pneumatic valves. P/N: EC-3-12 for the valve and P/N: C2-RB18 for a connectorized lead. One of these will be used for solder dispensing/component tape advancing, and the other is for the vacuum pickup system.
  6. Connected to the above valves, via blue tubing ( clippard P/N: 
    URH1-0402-BLT-050 ), is a pressure regulator, clippard P/N: MMR-1N.
  7. The valves and regulator do not come with fittings so I also ordered clippard P/N: 11752-5-PKG
  8. Next you can see a circuit board.  This custom job contains electronics for Opto-isolation, transistor amplification, and Back EMF suppression.  All of which allows us to switch inductive loads like relay coils and solenoids from our PC parallel port safely.
  9. Further to the right is a 12 V DC relay for switching the 110 V AC vacuum pump on and off.  The second set of contacts will eventually drive the vacuum solenoid to either create vacuum in the pickup needle line or vent to atmosphere. I'm not sure if these are available or not, mine is scavenged from an old project Omron P/N: MK2P-S-DC12
  10. On the very far right you can see a blue snubber that is wired across the aquarium ( vacuum ) pump.  I added this to reduce EMI on the 12 V Rail.  It was necessary.  ITW P/N: 104M06QC100.
So, that's kind of an overview of some components, that make the subsystems.  Let's talk a little more about some of the details of setting up the machine and how I intend to make this a useful robot instead of a list of cool parts.  This post will discuss setting up the Z-Axis probing and robotic solder paste dispensing.

Z-Axis Probing:

In case it wasn't already obvious, this entire project has been made so easy by those who have gone before me and were willing to write up their own findings.  Clearly, the best example of this is LinuxCNC, without which, nothing on my machine would be moving this early in the game.  LinuxCNC is powerful and customizable.  And thru adding some text to the configuration files, we can setup the probe functionality built into LinuxCNC, or perhaps more correctly G-Code. wrote up an article on how to setup Z-Axis probing.  This will allow me to know how high my pickup needle and solder dispensing needles are relative to the top of my circuit boards.  This is important because later on, when I write G-Code programs for the PnP I will need to reference the top face of the PCB.  Of course you could set the Z-Axis manually, but why would you want to?

Have a look at the picture above, and I will try to explain what happens when we probe the Z-Axis.  The aluminum block you see is 0.75" thick.  The wire connected to this aluminum block via a ring terminal is connected to the PC's parallel port ground.  The alligator clip, clipped to the same electrical point, is connected to the parallel port pin 13 on the other end.  What I just described is a closed switch as LinuxCNC sees it.  If we were to clip the alligator clip to the conductive needle instead, we would have a switch that closes when the end of the needle touches the aluminum block's top face.

If you were to call a probe command in G-Code it may look something like this:
G38.2 Z-2.500 F15

G38.2::G38.5 are probing codes.  In the case of the above code it reads: ( G38.2 ) Probe towards work piece, Stop on contact, Signal error if failure. adding ( Z-2.500 ) means that if you get to Z-2.500 before touching the probe surface, stop; something is awry.  The F15 is your feed rate.

So, F15 is fast for probing, right?  Especially when you consider that's tutorial implements debouncing for the probe signal.  IIRC, the debounce routine is 100 iterations of the base thread.  Say our base thread runs at 1 mS, well 100 iterations would be 100 mS, and 100 mS at F15 inches per minute equates to 0.0025".  In other words, if you just zoom down into the aluminum block and set Z = zero ( or 0.750" rather ), you will be 2.5 thou too low.  the answer is to slow down that feed rate and consequently decrease the overshoot.

Since we don't want to wait ages for a slow feed rate if we are a long way away from our aluminum probe block, I wrote the G-Code subroutine for probing as below.  If you read the comments you will see that essentially the code quickly probes down to the block, comes up a bit, then probe down slowly to get an accurate Z-Axis reference.

o100 sub

( Set current Z position to 0 so that we will always be moving down )
G10 L20 P0 Z0.0

( quickly probe down to touch off plate )
G38.2 Z-3.0 F15

( switch to relative coordinates )

( rapid up 0.1 )
G0 Z0.05

( probe slowly to get a more accurate zero )
G38.2 Z-0.2 f0.5

( set Z0.0 to be 0.75 above work surface - this is due to the touchoff plate thickness )
G10 L20 P0 Z0.75

( switch back to absolute coordinates )

( rapid to Z1.0 - probe tip is now 1" above work surface )
G0 Z1.0

o100 endsub

Below is a video of this Z-Axis probe action.

Now, after making my way thru the probe tutorial above, and modifying the G-Code subroutine for faster probing, I learned enough about how to make buttons appear on my LinuxCNC GUI, and more importantly, make those buttons do something useful.  So, I set out to make some more buttons to speed up the machine setup.  I made buttons for zeroing the X and Y axes as well as one to turn on my solder paste solenoid for 3 seconds to purge any dry solder paste from the needle.

To make this happen, I edited myCNCconfigName.ini such that the HAL UI MDI commands look like below:

HALUI = halui
HALFILE = 4axis_PnP.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

# add halui MDI commands here (max 64) 
MDI_COMMAND = o100 call 
MDI_COMMAND = o101 call 
MDI_COMMAND = o102 call 
MDI_COMMAND = o200 call 

Then I edited custom_postgui.hal to contain the following:

net remote-o101 halui.mdi-command-01 <= pyvcp.o101
net remote-o102 halui.mdi-command-02 <= pyvcp.o102
net remote-o200 halui.mdi-command-03 <= pyvcp.o200

And finally, I added the following to custompanel.xml

# add halui MDI commands here (max 64) 

So, when you press one of these buttons on the LinuxCNC GUI the respective subroutines below are called:
o101 sub

( Set current X position to 0 )
G10 L20 P0 X0.0

o101 endsub

o102 sub

( Set current Y position to 0 )
G10 L20 P0 Y0.0

o102 endsub

o200 sub

M64 P1 ( DO 1 ON )
G04 P1.0 ( dwell seconds ) 
M65 P1 ( DO 1 OFF )

o200 endsub

I will be revisiting this creation of buttons again soon.  I am thinking of how to probe the X and Y axes instead of manually setting the zeros.

Robotic Solder Paste Dispensing:

To start with this robotic solder paste dispensing problem, I decided to rig up a manual pneumatic dispenser.  With a switch connected to a solenoid, I was able to selectively apply CO2 to my syringe of solder paste.  The solder paste naturally escapes thru the dispensing needle, and the hope is, that the correct amount makes it onto the correct solder pad.

This sounds easy enough.  We have a fixed orifice, and a fixed pressure ( 40 PSI of CO2 ), so we should have a constant flow, and with a constant time, a deterministic volume dispensed.  What I don't have, however, is a fixed viscosity fluid.  My solder paste varies from dry to entirely too wet.  The reason for this, I think is that the paste is 2 years old, and it has a shelf life of 6 months.

All this means is that my time based experiments in this area are largely useless at this point.  I have ordered a new tube of solder paste.  This has proven to be a good learning experience.

Eventually the human operated switch was replaced by an opto-isolated, transistor amplified, and back EMF protected circuit, that means that I can now write G-Code to turn on and off this solenoid for a specific time period with the code:
M64 P1   ( turn D0 ON solder solenoid )
G04 P1.5  ( dwell seconds ) 
M65 P1   ( turn D0 OFF - solder solenoid )

Strap the digitally controlled solder paste syringe to the pick and place gantry, and you can do this:

Below is a picture of solder paste dispensing onto a piece of paper.  The 5 dots on the left were dispensed with a 1.5 second period, and for the 5 dots on the right the CO2 solenoid was open for 2 seconds.

Here is a video of the dispensing in action. You can notice that the first pad does not get enough solder dispensed onto it.  Given the viscosity disparity of this expired solder paste tube, and my elected method of application, i'd say these results are pretty good.

While the solder was being placed on the circuit boards, I was hand populating the components.  The resulting boards are just as good as they ever have been using a solder paste screen.  And certainly, one of the coolest features of robotic solder paste application is that I can make new boards while never having to purchase a ~$200 solder paste screen again.

Ok, well I can't think of anything else to talk about on this topic.  It's all pretty prototypical at this point, but I'd say its moving in the right direction.  And if you've made it this far into the reading, thank you; you're doing better than me.