FireStep release 0.2.4 is available

[Karl]

https://github.com/firepick1/FireStep/releases/tag/0.2.4

Tested on:

* Arduino Mega 2560 RAMPS 1.4 A4988 @ 200 steps/rev sysmv:18000 systv:0.8

* Arduino Mewa 2560 EMC02 A4988 @ 400 steps/rev sysmv:20000 systv:0.7

I also corrected information throughout the FireStep wiki and updated calibration instructions.

The Sliced Pulley Error kinematics are proving accurate and do indeed correct the not-quite-zero-level

problem I was seeing before with auto-calibration. I'd hazard to say that HAAC (Home Angle Auto Calibration)

may be "good enough for starters".  

Looking ahead, after reading Paul's note on MotionBoard status, I'm going to put some work into libfirestep for Unix machines.

I'll also create a command line Linux client for FireStep that will support PH5 curve generation. This

would complete the FireStep software suite (at least for Linux boxes) with support for collision avoidance

and hopefully help Paul out with command interpreter issues, since I'll be wading thru many of the same scenarios.

A Windows FireStep client should be very feasible, just not a priority for me right now, since I develop on Linux.

[Douglas Pearless]

Hi Team,

In case I am re-inventing the wheel, after looking at the various ULP programs that generate GCODE to drive various paste dispensers and not finding one I liked, I have started to write a pure java program that takes any .BRD file and generates the GCODE require to paste each of the SMD pads. I am interested in how the fiduciary alignment occurs currently in OpenPnP, noting it may be simpler to generate a bitmap of the solder pads on the PCB, light up the board so that the actual pads can be seen by openPnP (perhaps a certain colour??) and compare the two to find out where 0,0 is on the PCB is and therefore all the relative offsets required to paste the board.

A number of the ULP programs simply put a single do of solder paste on each pad which won’t suit all the different pad sizes, etc.

Has anyone written a similar program or have this working as I don’t want to duplicate any effort here (or go off on a crazy tangent) while I am waitng for my new J-Head to arrive (and my compressor for the solder paste dispenser too).

Cheers
Douglas

[Jason von Nieda]

Hi Douglas,

I'm in the process of adding solder paste dispense to OpenPnP right now. Preliminary versions should be starting to show up in develop within a week or two.

The solder paste will work similarly to how pick and place works now. It will use the same fiducial alignment (or manual alignment) and use the same structures as pick and place. It will just add importing of Gerbers to set up the paste operations.

Jason

Douglas

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

[Douglas Pearless]

Hi Jason,

Great to hear, I will stop work on my stuff as no sense in doing both!

BTW, which repo should I use to pick these new features up from?

Cheers

Douglas

[Rich Obermeyer]

I just wanted to point out that while eagle may work for some, it limits the usefulness of PNP for those that don't use eagle ulp scripts. I feel it creates a sense of hobby grade solutions.
I use Altium 3D myself and see no reason to install eagle just to run a ulp script so I could use PNP.
I have had to deal with eagle tools for some legacy projects and find it very painful to use after using a powerful tool like Altium.
I am not trying to convert anybody here to any package, just think using the paste layer of gerber files as Jason suggested can allow any cad package to work with pnp which makes more sense than wasting resources developing with tool specific solutions.

[Peter Shabino]

Dito on the comments stick to gerber or similar platform independent input data. I use Cadence Allegro professionally and switched over from eagle cad to kicad for home stuff a while back. So a eagle only solution would not be useful to me. But the good news is just about every package (well other than ones tied to a PCB house) can export gerber or other standard data formats. So in theory if you support that anyone can use it independent of their PCB CAD package. 

Later,
Peter

My projects:
http://www.wire2wire.org/

> Subject: Re: [FirePick] Eagle PCB to GCODE for the paste dispenser
> From: rich.ob...@gmail.com
> Date: Mon, 31 Aug 2015 23:00:55 -0700
> To: fire...@googlegroups.com

[Paul Jones]

I would imagine that once the "guts" of the program has been written it will be a simple matter to add support for any other formats. Jason's coding is impressively flexible :)

RE Altium v Eagle - Although Altium has some impressively handy features, I find it horribly irritating to use! The workflow of Eagle seems to match other cad tools I use so I actually chose Eagle over Altium. It gets the job done the quickest for me. I must be weird!

Paul.

> -----Original Message-----
> From: fire...@googlegroups.com [mailto:fire...@googlegroups.com] On
> Behalf Of Rich Obermeyer
> Sent: Tuesday, 1 September 2015 4:01 PM
> To: fire...@googlegroups.com
> Subject: Re: [FirePick] Eagle PCB to GCODE for the paste dispenser
>

[Jason von Nieda]

Hi Rich,

That's exactly my reasoning, and for the same reason OpenPnP uses it's own format for boards and jobs and allows you to import into those formats. OpenPnP is CAD agnostic and always will be.

Jason

[Douglas Pearless]

OK, I am curious on a couple of use-cases and how they will work from a gerber file perspective:

(1) User only wants to paste and mount SMD parts

(2) User only wants to paste and mount some parts (i.e. can select those parts they want to PnP and just those have the paste and components applied), say there are components that don’t do too well in a reflow oven.

The reason I was writing an XML file .BRD interpreter was I can then have a list of the pads associated with each component and allow the user to select just those they want to process.

Later, I was wondering if a future FPD iteration could have both a PnP head AND a solder paste dispenser in the same tool so you could set up a job and literally leave it until it is done, and so eliminate the need for a tool change twice per board and with some kind of loading-unloading mechanism would allow a small business / hobbyist operator to assemble a stack of boards with minimal interruption / interaction?

Cheers

Douglas

[Jason von Nieda]

Douglas,

I'll expand a bit on how this is going to work, and I think that will answer your questions:

Right now OpenPnP uses two XML files to define a job. They are the .job.xml and the .board.xml. The board XML file contains information about a single board design, like it's placements, fiducials, outline, etc. The job XML links one or more board XML files to a physical location on the machine along with some metadata about how the job should be processed. For instance, when adding a board to a job you can choose which side of the board to process. This is in the job XML.

What I am doing right now is adding pad data to the board XML. Using the same workflow of adding boards to jobs you will then be able to dispense solder paste to pads on a board. It will reuse all of the existing job handling stuff such as picking a side, finding fiducials, etc.

In addition, there will be a new tab in OpenPnP for paste dispense. Similarly to how the Job tab currently displays boards and placements, this one will display boards and pads. You will be able to select which side of the board you want to paste and which pads to include or exclude.

In the future, I would like to link pads to placements. This will allow you to specify things like include/exclude in a single place instead of two places. I have some thoughts on how to do this automatically with Gerbers but that is a feature that will come later.

The nice thing about this setup is that the code will be in place to link pads to placements - it will just be a matter of getting that data into the system. One way to do that will be to use a (yet untested) algorithm for Gerber processing. Another way would be to import an Eagle .BRD directly. And later other formats. It becomes a problem of adding new importers rather than changing how OpenPnP thinks about this data. 

Hope that helps. I'm interested in thoughts on comments, criticism, etc. on this design.

Jason

[Douglas Pearless]

OK,

I think the piece I am missing and what I was trying to solve, is that there doesn’t appear to be link between a “part" to the "pad data” in the gerber file(s), but by having an interpreter for each PCB package (Eagle, Altrium, etc).

My thoughts are by reading in the BRD file is that it (should?) contain all the data required to automatically define a board.xml, perhaps a translate that in this case, reads a file in a proprietary format and translates to the OpenPnP XML format?

Cheers

Douglas

[Jason von Nieda]

Douglas,

Yep, you are right. The way I see this is that pads (detached from placements) is step one, and is a must have. That's all we "need" to do solder paste. Having those pads attached to placements is a nice to have that lets us optimize the UI but it's not really required to get moving. That's why I see that as something to come later.

And yes, loading a BRD file would give us everything we need all at once, but my first goal is compatibility and I get lots of that by loading Gerbers first.

I do intend to eventually support direct BRD import. I've already written a lot of the code for it. It's just not a very high priority because by supporting centroid files and Gerber files I can cover ALL CAD packages instead of just one, albeit with a little less functionality.

Jason

[Douglas Pearless]

OK, I might muck about with some Java code and reading the BRD file for a day or so to satisfy my curiosity as it is quite a while since I mucked about with XML.

In reading the sample EAT001.board.xml file, I note it has the package details are in there, so I guess all it needs is a parts database that has the pad information for the parts (and variations there of)?

Cheers

Douglas

[Jason von Nieda]

Douglas,

It's both easier and more complicated than that. All of the data you need is in the BRD file. In EAGLE, when you create a BRD file it includes all the data from the library (LBR) file in there. The problem is that the cream layer is dynamically generated based on rules, it's not explicitly included anywhere. What you'll find is that in the BRD file there is a package definition for each part you've included in the board, for example:

<package name="R0805">

<description>&lt;b&gt;RESISTOR&lt;/b&gt;&lt;p&gt;</description>

<wire x1="-0.41" y1="0.635" x2="0.41" y2="0.635" width="0.1524" layer="51"/>

<wire x1="-0.41" y1="-0.635" x2="0.41" y2="-0.635" width="0.1524" layer="51"/>

<wire x1="-1.973" y1="0.983" x2="1.973" y2="0.983" width="0.0508" layer="39"/>

<wire x1="1.973" y1="0.983" x2="1.973" y2="-0.983" width="0.0508" layer="39"/>

<wire x1="1.973" y1="-0.983" x2="-1.973" y2="-0.983" width="0.0508" layer="39"/>

<wire x1="-1.973" y1="-0.983" x2="-1.973" y2="0.983" width="0.0508" layer="39"/>

<smd name="1" x="-0.95" y="0" dx="1.3" dy="1.5" layer="1"/>

<smd name="2" x="0.95" y="0" dx="1.3" dy="1.5" layer="1"/>

<text x="-0.635" y="1.27" size="1.27" layer="25">&gt;NAME</text>

<text x="-0.635" y="-2.54" size="1.27" layer="27">&gt;VALUE</text>

<rectangle x1="0.4064" y1="-0.6985" x2="1.0564" y2="0.7015" layer="51"/>

<rectangle x1="-1.0668" y1="-0.6985" x2="-0.4168" y2="0.7015" layer="51"/>

<rectangle x1="-0.1999" y1="-0.5001" x2="0.1999" y2="0.5001" layer="35"/>

</package>

And then later there will be element references for those packages, defining where on the board each one is:

<element name="R1" library="rcl" package="R0805" value="" x="19.05" y="17.78"/>

What you'll notice is that there is nowhere that the cream layer (31 or 32) is defined. This is because the cream layer is generated dynamically based on the combination of the <smd> elements in the package along with the global DRU parameters, example:

<param name="mvCreamFrame" value="0"/>

<param name="mlMinCreamFrame" value="0mil"/>

<param name="mlMaxCreamFrame" value="0mil"/>

I am not quite sure what the relationship between the parameters and the size is yet, but it should be easy to figure out by testing the CAM generation with a few parameters.

Anyway, if you want a jumping off point for parsing the files, check out: https://github.com/openpnp/openpnp/tree/develop/src/main/java/org/openpnp/model/eagle

That is an XML reader for the Eagle file formats which I generated based off the DTDs.

Jason

[Douglas Pearless]

OK, I will have a read of that code. :-)

[Rich Obermeyer]

While we are on the subject, what is the strategy to get a gerber based paste layer converted into a .2mm paste dispenser?

Even a 0805 resistor will have a square pad on the gerber.

[Rich Obermeyer]

Hi Jason,

You asked for feedback, don't waste a lot of time with eagle specific importers.  I am sure it's a nice goal, it only benefits one class of user.

All board packages can generate an accurate paste layer and most have some rule parameter that would allow increasing or decreasing the size of the pads based on the equipment being used.  By using gerber paste layer data you should be able to place paste on any PCB without having access to the tool yourself.

Secondly, where are you getting placement data from?  Gerber doesn't have location information.  Most packages generate a .pnp file that defines all component info for placement.  Are you using that or something else?

Regards,

Rich

[Karl]

Uh. Y'all should maybe be posting to a new thread where we can find your awesome posts easier?

Somehow all these exchanges are showing up under a FireStep thread.

:D

[Jason von Nieda]

Sounds like you have an email problem Karl. This thread started with Douglas's message titled "[FirePick] Eagle PCB to GCODE for the paste dispenser"

Jason

--

[Michael Anton]

Actually, Karl is correct.  If you look in the Google group directly, this thread is part of the FirePick V2.4 announcement.

Mike

[Jason von Nieda]

Hi Rich,

As I said, Gerber is first, Eagle specific will come later. There are benefits of importing Eagle files directly (along with other native formats for CAD packages) in that you get to skip a few steps and you get more data, but that is phase 2. Phase 1 is import Gerber and put down paste.

For PnP, OpenPnP currently supports importing centroids from Eagle mountsmd.ulp output and KiCAD .pos files. Both are pretty simple whitespace delimited text files. I don't know of any single standard .pnp file. If you do, please let me know and I'll be happy to support it. 

Jason

Douglas

Douglas

Douglas

[Rich Obermeyer]

I suspect someone changed the subject line which saves the thread but confuses us all.  I moved it to a separate discussion.

Sorry.

[Douglas Pearless]

Hi Jason,

I have been playing around with the XML Reader from  https://github.com/openpnp/openpnp/tree/develop/src/main/java/org/openpnp/model/eagle with the EAT001 sample board and I get an interesting error in the EagelLoader class.

This line  

Library library = (Library) drawing.getLibraryOrSchematicOrBoard().get(0);

returns the error “org.openpnp.model.eagle.xml.Board cannot be cast to org.openpnp.model.eagle.xml.Library”

in examining the underlying variables:

I can see the first object in “libraryOrSchematicOrBoard” is “Board” but that is the only object (the next one in the elementData is null) and I assume the 

drawing.getLibraryOrSchematicOrBoard().get(0) 

always returns the first object which is “Board”, which it cannot cast to “Library”.

Before I (further) tear the code apart, should there be a “Libraries” object, or should I traverse the “libraries” element inside the “Board”?

Am I missing something obvious here?

Cheers

Douglas

[Douglas Pearless]

Hmm, I think I may be able to now answer my own question.

If the user opens a “.brd” file, then the object will be “Board"

If the user opens a “.lbr” file, then the object will be "Library"

If the user opens a “.sch” file, then the obecj will be a “Schematic”

So, in the case of a “Board”, I simply traverse objects within that, e.g. Libraries, to gather all the bits I need to then process per the other “Import” examples.

Same for “Library”

Is that correct?

Cheers

Douglas

On 5/09/2015, at 3:23 pm, Douglas Pearless <douglas....@gmail.com> wrote:

Hi Jason,

I have been playing around with the XML Reader from  https://github.com/openpnp/openpnp/tree/develop/src/main/java/org/openpnp/model/eagle with the EAT001 sample board and I get an interesting error in the EagelLoader class.

This line  

Library library = (Library) drawing.getLibraryOrSchematicOrBoard().get(0);

returns the error “org.openpnp.model.eagle.xml.Board cannot be cast to org.openpnp.model.eagle.xml.Library”

in examining the underlying variables:

<PastedGraphic-1.tiff>

[Douglas Pearless]

Well, I was unable to sleep last night and I now have a almost full functional Eagle PCB “.brd” importer working that also has the same option to “Create Missing Parts”.

The one piece I have yet to be able to figure out is how to determine whether a part is on the Top (layer 1) or the Bottom (layer 16).  When I have figured that out it will work properly.

The net result is that we won’t need the moundsmd.ulp or any other conversion process for Eagle PCB, simply open the .brd file and process it and this could be extended to other file types as required; or people can use the gerber method.

Does anyone have any ideas as how to work out which layer a part is on from the .brd file???

For those who do not use Eagle PCB, we probably need to write importers for Altrium and other packages?

Cheers

Douglas

[Michael Anton]

I use Altium Designer (well not really, but I own a seat), and P-CAD.  P-CAD can generate pretty much any format as long as it is comma separated, so something like a CSV import would work well for me.  It is also a format that is easy to massage other formats into.

Mike

On Saturday, September 5, 2015 at 3:31:14 PM UTC-6, Douglas Pearless wrote:

<snip>

[Douglas Pearless]

I now have a working imported for Eagle PCB .brd files, you no longer need to run the mountsmd.ulp then process the .mnt and .mnb files; you simply import the .brd file :-)

When Jason releases his paste code, it will be interesting to see how this integrates with that as it uses exactly the same interface as the other board importers :-)

I will figure out how to submit my changes back to the repo...

Cheers

Douglas

[Douglas Pearless]

If I have done it properly, Jason you should have received a pull request from me to add this functionality to openpnp.

Cheers

Douglas

[Rich Obermeyer]

Douglas,

This is very cool.

I have asked for the PNP files for the two firepick camera light board and all I get is a link to a .brd file which does me no good since I don't have Eagle installed.

Now I can maybe use the .brd files.

Thx

--

Rich

[Rich Obermeyer]

Peter,

You have a sample Allegro PNP file to compare to the other ones supported already?

Rich

[Douglas Pearless]

If you want to try it now, it is all there on my openpnp repo:  https://github.com/DouglasPearless/openpnp have fun!

Sent from my iPhone

[Jason von Nieda]

Thanks Douglas! I have merged the pull request, although I am having some trouble loading a simple Eagle file. I suspect it may be a versioning thing. Do you happen to have a .brd file that it loads properly so I can compare the differences?

Thanks,

Jason

[Douglas Pearless]

The EAT001 file in your samples loads just fine :-) ( i have also tried the EAT001 from the firepick repo too.)

I am making some changes to allow a user to specify top and / or bottom parts to load.

If you have issues, let me know what the symptoms are and I will look at ti.

Cheers

Douglas

[Jason von Nieda]

Hey Douglas,

I am getting the same error on that file as well. This file specifically: https://raw.githubusercontent.com/firepick-delta/firepick-delta/dev/electronics/EAT0001/EAT0001.brd

I get an empty error dialog when I try to parse it, and if I drill in the exception is this:

Exception in thread "main" javax.xml.bind.UnmarshalException

 - with linked exception:

[java.net.MalformedURLException]

at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:246)

at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:214)

at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:140)

at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:123)

Are you not seeing this same error?

Jason

[Douglas Pearless]

Hmm,

I had removed the unmarshall stuff from my code; maybe I pushed the wrong version.

I have added new features (the ability to specify which sides of the board to import) and submitted a new pull request.

Try this as it definitely works!

Let me know how you get on.

Cheers

Douglas

[Jason von Nieda]

Same error. Can you send me, via email, your working EagleLoader.java? Perhaps something is not being merged or pushed correctly.

Jason

[Douglas Pearless]

Done

[Douglas Pearless]

Note: I am running mine from Eclipse and followed the FirePick installation instructions (if that helps)

[Jason von Nieda]

Okay, I will look into this further in the coming week. In the meantime, if it's working for you that's good enough :) I'll figure out what is going on on my end.

Jason

[Peter Shabino]

It is just plain gerber / IPC data will have to do some digging and see what I can find. 

Later,
Peter

My projects:
http://www.wire2wire.org/

---

Date: Sat, 5 Sep 2015 21:12:48 -0700

Subject: Re: [FirePick] Eagle PCB to GCODE for the paste dispenser
From: rich.ob...@gmail.com

To: fire...@googlegroups.com

[Rich Obermeyer]

Peter,

Not gerber, although that will be useful later when the paste code is done, see if you have the text pnp file that checks the pick and place work.

[Jason von Nieda]

Hi Douglas,

I fixed the problem that I was experiencing in the Eagle loader. It was kind of an environmental issue, but I changed a few things to make it more robust in general.

Have a look: https://github.com/openpnp/openpnp/commit/0c1eb2e291793eedaa948f042a42b0888823ab86

The primary change was just moving the eagle.dtd to a better place in the repo and referencing it there. It doesn't really change any functionality. I also added some tests.

Let me know if you have any problems with this new version. You may need to run a mvn clean or Clean Project within Eclipse before it will work.

Jason

[Douglas Pearless]

Hi Jason,

Yep, happy with the changes, no problems with the required set up change.

One quick question, is there an easy way for Eclipse to pick up the changes, I assume I need to install a git plugin for Eclipse, if so, which one do you use?

I cannot wait to finish the Eagle import code so I can test it !!

My thoughts are to photocopy the PCB onto paper and load the paste syringe with a flour and water paste so I can try this  without wasting expense solder paste :-)

Also, I believe we need a weight parameter for parts so we know which nozzle should be used (to minimise heavy parts falling off i.e. a large nozzle, while still allowing tiny parts that are too small for a large nozzle to be picked, i.e. a tiny nozzle) I am looking at designing an auto-changer that allows the FirePick PnP head to change nozzle tips as required.

Cheers

Douglas

[Jason von Nieda]

Hi Douglas,

I don't use a Git plugin, so I can't recommend one. I use SourceTree to update my repos and then just right click the project in Eclipse and choose Refresh. Works a charm.

Right now the solder paste stuff is working but it's kind of in a phase 1 state. Later this month we'll be working to make it much more robust and to be better able to handle different package types. Right now it just puts a single dot in the center.

As for part weight, there is already a built in way to handle nozzle tip changes. OpenPnP supports by default a three point nozzle tip changer and the ability to specify which parts should use which nozzle tip. It also tries to be smart about how often it changes them. Look at the configuration settings for nozzle and nozzle tip in Machine Setup panel. You'll want to turn on Changer Enabled? in the Nozzle and then set the three points for each Nozzle Tip you have.

The three points are three points that the machine will move between in a straight line to load or unload the nozzle. It does them in reverse for unload and forward to load.

Jason

[Douglas Pearless]

OK, I will stick with the same method of using Git.

So, is the code at a state where I can get the next part of the Eagle importer working?

Lastly, I will design a tool holder for FPD that works with OpenPnP as it is.

Cheers

Douglas

[Jason von Nieda]

Yep, you can go ahead with the Eagle importer updates. I will be merging the paste-dispense branch into develop in the next day or two after a little more testing.

Here is how to use it, and a little about integration:

First, once you sync your code and run OpenPnP again it should update your machine.xml. It will remove the existing job-processor and job-planner lines and rearrange them a bit. Do this before doing anything else.

Next, you will need to add a paste dispense job processor and a paste-dispenser head object. I don't have UI for these yet, so you have to edit the machine.xml by hand. See here for the changes that need to be made, roughly:

https://github.com/openpnp/openpnp/commit/00b4ee13f4df7e1fd7033158ca8662560ffa8f66#diff-0bdc7b5af235ab23d66ff9fc7db3e67cL1

Now when you start OpenPnP you should see a new tab in the job area called Solder Paste. It's similar to the Pick and Place tab but references Pads instead of Placements. Starting a job with that tab open will run a Solder Paste job, starting the job with the Pick and Place tab open runs a pick and place job.

Take a look at the SolderPasteGerberImporterDlg for a clue on how to implement import for Pads:

https://github.com/openpnp/openpnp/blob/feature/paste-dispense/src/main/java/org/openpnp/gui/importer/SolderPasteGerberImporterDlg.java#L166

Basically, Pads are very similar to Placements except they describe a shape as well as a point. There are some basic implementations of various shapes that you can use. Most likely you will only need Pad.RoundRectangle to get things rolling with Eagle.

Finally, you will need to update your driver to handle the dispense() method. Eclipse will bitch about it so it should be easy to find.  Here is how mine looks currently:

@Override

    public void dispense(ReferencePasteDispenser dispenser,

            Location startLocation, Location endLocation,

            long dispenseTimeMilliseconds) throws Exception {

    enableDispenser(true);

    Thread.sleep(this.dispenseTimeMilliseconds);

        enableDispenser(false);

    }

You'll need to play with this to suit your dispenser.

Good luck, and let me know if you have questions.

Jason

[Jason von Nieda]

Hi Douglas, wanted to let you know that the paste-dispense branch is now fully merged into develop and includes a default config for dispense. 

Jason

[Douglas Pearless]

Great, I will have a look tomorrow.

[Douglas Pearless]

Hmm,

I followed the instructions but have done something wrong, I do not see the extra tab in the jobs area called “Solder Paste” (and I did updat the machine.xml in the .openpnp directory.

If I try to import gerber files I now get:

Thoughts?

[Jason von Nieda]

Hi Douglas,

Please send me your machine.xml. I suspect one of us just missed something.

For the Gerbers, it looks like you are actually importing Eagle mountsmd.ulp files, not Gerbers. Try pnp-test-OpenPnP.GBP and pnp-test-OpenPnP.GBP from the same directory.

Finally, have a look in the support directory for OpenPnP-EAGLE.cam, which is an Eagle CAM job that will generate Gerbers appropriate for import for any other boards you might like to try.

Jason

[ric...@hornbaker.com]

Hi, Jason.

Regarding head changes, what is the common practice for securing and removing the tips?

For example, I'm wondering if the effector has to pull up to dislodge the head (and press down to seat it fully), and if so whether that affects calibration in the Z axis. Does the unit need to check at least Z after each change, if not also homing to ensure its still accurate?

I imagine a very mild magnet would be enough to hold the head in place and fully seated. And the seal would need to be airtight enough for the vacuum pickup, but not so tight as to make head changing mechanically difficult.

Just wondering if a mechanical assist is needed in the head changer itself with better mechanical advantage to seat / unseat the head during the cycle.

Cheers,
Richard

[Douglas Pearless]

I have been experimenting on this topic myself.

So far I have determined that the magnets that hold to tool head to the AFD is too strong to simply pull apart, instead tool head has to be rotated until the magnets disengage, then they can be separated.

I am trying to work out the optimal (read cheapest way) to achieve this, and I have come to the conclusion that it *may* be best to have a series (say 4 or 5) tool holders that have a cheap servo built into them so that the AFD is positioned horizontally ‘into’ the tool holder, which uses a servo to rotate the tool head to disengage it, then the AFD can be moved down and away from the tool, across to the next one, where it can approach from the bottom, and the servo in that tool holder then rotates the tool so the that magnets engage and the AFD moves away horizontally with the new tool. Note each tool holder has a method of detecting if the is a tool stored in them, it might be a cheap microswitch or maybe led+detector; ideally each tool head can be uniquely identified as to where it is. I am also looking at can these be design in such a way that the sit on the frame, sufficiently high up so they do not interfere with and feeders below.

This is the only way I can reliably see to enable automatic tool changing with minimal stress on the AFD and hence to not affect the calibration as having to run a calibration per tool head change would be problematic (as the bed has something on it, for example PCB, then solder paster, then PnP = two tools required).

I have also been working on designing a combined 3D Print waste dump, hot-end cleaner and PnP tip holder (this is the two superbly machined vacuum head parts).

This is a single 3D printed part that has:
(1) A Silicone cup-cake mould placed into it (these are very cheap to buy) to act as a waste dump for hot filament, solder paste and waste SMT parts
(2) A piece of non-metal ‘brillo’ pad (i.e. kitchen scrubbing pad that is made of plastic not metal) for which the hot-end is dragged across and is cleaned (but not a full temperature), special g-code is added to the start and end of print jobs until I write / create a M-code to ‘clean the head’ - which will take the J-Head to a temp where the filament is soft enough to wipe off, but not too hot to melt the ‘brillo’ pad, and go through a defined path (with dwells) to clean any surplus plastic, then move to the dump area, heat up the hot-end to full temp, extrude some filament, retract the filament a bit, cool down to the required cleaning temp wipe and cycle this several times). I have been intrigued to see a commercial 3D print that uses a fixed thin piece of metal to ‘wipe’ the hot-end tip against to clean the hot-end)
(3) a holder for the two metal PnP tips that allows the PnP head to come down onto the tip and the pull it away horizontally, and visa versa to unload. I have test this and there is very low pressure on the AFD and it does not seem to effect aclibration.

I am making slow progress on these as I am:
(A) completing the OpenPnP code to import an Eagle .brd file (I have the parts working, just need to complete the pads; hopefully this week)
(B) just starting to help Arthur develop the Smoothie2 firmware, which gives full floating point on Smoothie (and therefore the MotionBoard with the M4 processor) and moves to a proper RTOS; I am about to allocate 8 hours++ per week for this at the moment
(C) trying to fine tune the 3D printing as the fine details (like screw holes) are being filled in, I suspect it is an issue with the feed rate of the filament, mayebe the temp (I am using 185C for PLA) or the filament I am using (trial an error), I have reduced the slices to 0.1mm and print speed to 25% of normal and while better, it is still not good enough.
(D) grinding my way through FreeCAD for my design work as I do not have Cubify (I use Mac not Windows, but do have a windows 7 instance running under VMWare Fusion on one of my Macs) and it is very slow going.

Cheers
Douglas

[Peter Shabino]

Douglas,

Hey have you found any good tutorials on FreeCad? 

Can draw just about anything I want in google sketchup (including the stuff sketchup does not want to do like coils) but sort of at a loss on how to make a Pipe T fitting in FreeCad (can make parts like pipes long as they are symmetrical around the center line). 

Thanks,

Peter

My projects:
http://www.wire2wire.org/

> Subject: Re: [FirePick] Eagle PCB to GCODE for the paste dispenser

> From: douglas....@gmail.com
> Date: Thu, 17 Sep 2015 09:36:19 +1200
> To: fire...@googlegroups.com

[ric...@hornbaker.com]

Hi, Douglas.

For what it's worth, tossing an idea into the ether...

If a mechanical assist is needed, I envisioned a single mechanism for the bank of heads. Essentially, the bank would have a stationary portion that contacted the bottom of the effector, and the bank of heads would move vertically beneath it.

A flange on the head would engage the lower portion of the bank, which would retract downward to separate the tip from the effector (which is resting against the stationary top part, so no strain is applied to the arms).

The reverse could be applied to seat a head. Something like this would allow for stronger magnets if desired.

What I wonder is if the process can be made consistent enough to not require recalibration after each head change (both for rotation of the head for XY compensation, and for Z).

I also wonder if the seat can be designed in a way that a contaminated magnet won't screw up the fit. That is, if the magnets form the mating surface, any clutter that sticks to them will cause calibration problems.

Maybe magnets aren't the best option, and a friction-fit with O-rings is more reliable / simpler / more compact. If positive mechanical pressure can ensure the tip is fully seated during a change, maybe a better option.

FWIW,
Richard

[Douglas Pearless]

I have no particular favourite FreeCAD tutorial, I just searched the net and kept trying it myself ( and had some assistance with someone who also was trying it too).