Yet another feeder design...

[Robert Walter]

Hi all,

I have a feeder system in the works (yes, another feeder idea) and I hope to have 3d models and a prototype done before Christmas. The design will be released to the community for non-commercial purposes. Personally, I am a big fan of open source, but I also know that people need to feed their families, so hopefully everyone can understand and appreciate that.

In any case, the feeder will be modular (ie, easily removable from the machine for tape loading / unloading) and easily built within minimal components. Feeders will hang and align on two horizontal shafts with slots to maintain spacing.

The main structural plate could be cut using many methods, ie laser, waterjet, jigsaw. I am keeping things extremely simple, so no bending / forming should be necessary. All of the other components can be 3D printed or machined on a lathe / mill for production. In any case, the prototype / small quantities will be able to be produced using a 3D printer and a CNC router and basic hand tools.  

Indexing of the tape will be completely automatic, controlled by a low cost microcontroller. and will receive commands from the PNP via a distance I2C bus, or via a logic signal (5V). My company already has written a suitable library for distance I2C which resides in less than 1K on a ATTINY mcu. We have tested to 100' (30M) with no issues. So essentially a simple command sent to a feeder using its I2C address could consist of only the index length, and the feeder would do the rest. I already have RS232 serial / USB to distance I2C bridge working in a commercial product, so we can control feeders directly from OpenPNP or more simple / cost effectively if we implement our I2C stack directly on a TinyG board, etc.

I would like to have all feeder control via the OpenPNP software. No buttons on the feeders if possible. They add cost, and increase layout complexity. Ideally just a 2,54mm header to set feeder address on the bus. In time a feeder slot connector which mates to the feeder when inserted in the machine would be idea, to not only supply power, but to also provide slot ID to the onboard feeder MCU, so feeders are based machine position, rather than actual feeder node address on the network. More electrically / mechanically complicated, but more in the style of the big boy PNP's.

I have the drive system pretty much worked out, as well as cover tape take up, and tape guidance. First prototypes will be a straight through design, as it is what will fit my current machine best, but if vertical clearances exist on future designs / machines, a wrap around / bottom / back exit for spent tape will be easy to implement. My machine just does not have the room to wrap back under the feeder. I am limited by the low pick and place head height. Currently, the top of tape is 25mm from the mounting base.

I am still working out some details as to how to reliably determine tape position. I have some good ideas (about 3 different methods) but yet to decide upon / build any of the designs. All designs use a sprocket to track holes in the tape. Since tapes come in paper, clear, and black plastic, optical sensing is likely a no go.  The gear / sprocket method seems best, but it is a relativly high precision (read high cost) part to make. So I am trying to avoid this method, but it may be the only / best method. Reading the sprocket teeth is relatively easy. In any case, tape holes will be read in real time using some form of absolute position encoding. This is so we can not only catch the final position, but utilize the feedback to reliably close the motors speed / position loop to ensure smooth, high speed indexing. I plan on using a single low cost, miniature gear motor to drive the mechanism.

Current design is just under 15mm in total width. So it is pretty high in overall density.I would like to keep cost of components under the $15 to $20 mark. It could likely get under $20 with volume, but time will tell.

All in all, I just want something that works reliably, is NOT a drag feeder, and can be removed from the machine and reloaded without disturbing other reels / feeders in the process.

I hope to throw out some 3d renders in the next couple of weeks, but work is keeping my busy, so please be patient.

Any comments would be appreciated.

Rob.

[Rich Obermeyer]

Will it work on a Firepick machine?

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/945a165b-a027-4a26-8497-29659d432741%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Robert Walter]

Rich,

Theoretically, the feeders could work on anything. I haven't finalized the design, but the current design locates the closest part of the cover tape takeup reel about 42mm immediately behind the center of the pick up position The tape reel rises above the top of tape 70mm, so as long as your pickup head assembly does not occupy an envelope larger than roughly 40mm radius from center of pickup nozzle, you should be ok.

From my initial views of the firepick, the head assembly looks pretty large compared to a traditional pick and place. First designs may have some mechanical interference with the firepick head assembly. But that is not to say that the design could not be modified to create a larger pickup area clearance for the firepick. Time will tell. 

In any case, I sized the cover tape reel to be sufficiently large to be able to accommodate a full reel of paper tape cover. Hence the large diameter of the reel. We also implemented a magnetic outer spool end cover plate and a cover tape end catch mechanism, in order to make attaching the end of the cover tape to the take up reel (no adhesive masking tape, etc), and also so that removing the spent tape is easier.

Still thinking of a cost effective, simple way to make the entire cover tape reel removable, but that one still eludes me.

Hope that helps

Rob.

[Dustin Kasel]

What is the advantage of using I2C over a more traditional PHY layer such as RS485? Both use the same number of conductors but RS485 is much easier to implement. I'm just always curious why I2C is chosen when it's not a hard requirement given it's complexity (write, then read, etc).

[Jason von Nieda]

FWIW, I agree with RS485 vs. I2C. I've had a lot of trouble with I2C in noisy environments, especially with solenoids and motors turning off and on. It's possible to clean all that up with proper filtering but RS485 tends to be more resilient to begin with.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/59ceef8d-4a9e-4b7b-8f30-7d2884f13def%40googlegroups.com.

[Rich Obermeyer]

I can say I have been the master of I2C in noisy environments and its a bad idea.  Motors and relays shift ground and I2C hangs  forcing power down with most I2C slaves.  RS485 in the same world works flawlessly.

I have had I2C systems in this environment (vending machine) that worked for months and then a small change in cabling and it stopped working.  pretty short cabling and load.

It needs some kind of differential interconnect.

Why not USB? 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwc92aR4qu-4EfKUVCSTkcFWaKBt%2BQD%3D1qOnEH%3DD8CpYg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Robert Walter]

Dustin

Albeit this is a very quick answer to a  topic that can be debated until the cows come home..... I will try and shed a little light on my design ideas. Excuse the ramblings / orderness. I am working on three things at once today.

#1) I2C is in built into almost every low cost IC in hardware ($0.60 in quantity). Most low cost MCU's do not have hardware serial. Yes it can be implemented in software, but it gets messy with baud rates, software polling and frequency drift. I am trying to keep keep the cost of a completely automatic feeder extremely low, so every dollar or two helps tremendously. Personally, I want to build 100+ feeders, so costs add up quick.

#2) I am especially familiar with the Atmel ATTiny I2C implementation. It works really well, and I have written some pretty reliable libraries around it for master / slave communications. Since it is all done in hardware, and is completely event driven, it is extremely fast, and very lightweight in terms of required processing power. This leaves lots of room for motor control and position control on the low cost mcu. Also, aside from being able to go ultra-cheap using straight 5V TTL logic I2C, there are low cost I2C transceivers available for low cost that come from the HDMI / DVI market for extending length while maintaining speed. For hobbiest, 5V TTL I2C should be more than sufficient at low speeds, commercial implementations could exploit a transceiver at minimal cost, yet no software changes. Also since the master controls baud rate synchronously, moving feeders around is really easy between machines, as baud rate is machine dependent, not feeder dependent.

#3) The final communications from the feeders / feeder banks to the PNP controller or to OpnePNP can be anything. Going I2C to another MCU (like a TinyG, makes more sense as it uses much less overhead in the MCU, which likely is already fully taxed by the motion control software. From a PC, using a single communications controller / bridge also makes more sense, as it allows many low cost feeders to talk to the computer via a more computer friendly netowrk (RS232 / USB / Modbus / etc) without having large code bases and complex communications cabling between the feeders and the bridge. Also, the RS232 port on the TinyG is occupied for PC comms, so once again, it starts a snowball effect in terms of exploiting whats available at the controller or PC level.

#4) Existing IP. I have most of the software libraries / code in my exiting company archives to do the software in little to no time. I can other than writing some custom motor driver code, and position tracking code, all of the feeder I2C communications, including bridge from I2C to Serial, USB and Modbus are all done. I don't want to reinvent the wheel.

#5) RS232 is kind of dead anyway. In reality, you don't see serial ports on too many computers. Only USB to RS232 adapters. USB is too expensive to implement on each feeder, and messy cabling requirements, but being able to directly plug a bank of low cost feeders (up to 255) in directly via USB is a nice way to do things.

#6) Single voltage. I am trying to run each feeder on 5V. Technically, if I play my cards right, one high current USB connection (5V @ 1A), or two standard USB ports (2 x 5V @ 500mA) could power an entire bank of 255 feeders if only one feeder indexes at a time. 

Just my $0.02 worth. But I have a lot of wishes for these feeders, and a super low budget to get there in terms of cost per feeder. Hopefully my ideas make sense. if anyone wants to throw some better ideas, I am all ears...

Rob. 

On Friday, November 6, 2015 at 12:10:07 PM UTC-8, Robert Walter wrote:

[Rich Obermeyer]

Robert,

You can buy a USB to serial chip from Microchip for under $1.00 so I don't think that's any selling feature for I2C.  Connect an RS485 transceiver to the microchip and your golden.  Same chip does I2C, serial and SPI.  Drivers on the web.

You mentioned nobody eats for free.  Are you planning on selling these items or open sourcing so they can also be modified and built by others?

Sounds like you have some existing code that you might not want to give out to users so freely.

If you are going to be done by December you will most likely beat Firepick to market on feeders.  How is your delta design skills?

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3c810581-b582-4b3c-b93b-6b700a351347%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Robert Walter]

Typically, I have been using the PCA9614 on our commercial products, with absolutely no issues when placed in electrical control enclosures. Albeit it is differential as is RS485. But in these applications, distances can range up to 100+ feet, and we are hitting 38Kbaud at 100feet without issue.

Also, we implemented a CRC error checking layer to ensure data integrity. 

Anyhow, I totally get what you all are saying, and agree in many respects. I just think (maybe I am wrong) that if done correctly, I could get it all working using a very low data rate, since not much traffic / overhead is necessary. Probably 120 to 300 buad will work, as in reality, only a few bytes of data need to be transmitted to a feeder. Essentially the address / read-write header, a feed distance in mm, and a CRC checksum. So technically 3 - 4 bytes.Noise will hardly be an issue at this speed. over  the short distances between feeders and the feeder bank bridge.

Even at 120 buad, using 4 bytes per feed operation, we are easily in the 3 feeds per second range. That is 10K+ feed operations per hour which should easily keep up with most hobby machines... I am still not sure it the feeder mechanics will keep up with 3 feeds per second from a single feeder. Most single head table top machines are 3000 operations per hour.

As said, bridging simplicity / cost with functionality is the challenge and  goal for this project. Sure we could build a robust, professional grade feeder, but it would have the price of one too... Most hobbyists would balk at a $50 - $60 feeder. Neoden just released their 4th gen system, and $60 per 8mm feeder is the retail price, and theirs is not removable. Hopefully I / We can come up with something better. 

Rob.

[Rich Obermeyer]

Agreed high throughput is not a factor.  Its not about the speed.  I2C can easily hang on the first byte at 100k and ruin your whole day.  Debug that if you got 16 feeders connected.....:-(

RS485:

As you mentioned you could drive 250 feeders with one RS485 at any speed. Hot swapping is not an issue.

Expand-ability is endless with RS485 packets.  

Noise is not an issue.  

Simple cabling solution can be implemented.

No ground loops.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5c2d1abd-0365-4a80-9c4b-b9e0e3b6a38f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Michael Anton]

I'll third that one.  RS485 is much more suitable for high noise environments.  Sure maybe I2C can be made to work, but why?  It was never designed for that purpose, and there are better options, so why bother with it?  To me just because something can be made to work, doesn't mean it should be done.

Mike

[Robert Walter]

Rich,

Not too worried about Firepick. I am not in the business of building feeders to begin with. I just wanted to design one as a fun little project. I am not trying to beat anyone to market.

My goal isn't so much that I have to go I2C. I just have done some existing work that I think will facilitate quick development. If it works, great, If not, it is easy to throw money at a problem. Technically, a dip switch bank to set feed travel, and a contact closure / 5v signal is all that is needed to index a feeder. A little creativity, and you could one-wire it and make it work for really simple comms. The feeder doesn't need to talk to anyone, it just needs a index command, and for ease of use, a distance. A tape cover sensor would be a neat idea, but comms would have to be two way. Doable, but then adds sensing into the mix to detect a full cover tape spool.

I threw this idea up, and really didn't expect the challenge on the electrical design concept. It really was the least of my concerns, as most feeders are mechanical works of art, that are extremely complex, with lots of small highly machined / stamped parts. Anyhow, it is nice to see lots of ideas coming out, as it shows the activity in the forum.

I just wanted to try and put something up that the hobby community can benefit from.

In terms of financial gain, not doing this for money. I just figure that if a hobbyist wants to use my design for their own purposes, they are free to do so. If they want to sell my designs with their "for profit" machine, well then, they can help top off my toy fund in the process. I would expect this of any open source project being commercialized by a third party. But that is a whole other argument. In terms of some of my software that I wrote for I2C comms, it isn't rocket science, mostly compiled from reading lots of app notes from Atmel, and some basic papers written on serial comms and CRC calculations. My world would not fall apart if I released it as open source for non - commercial use. 

[Paul Jones]

I’ve had good success with I2C in noisy industrial environments.  Obviously you need to know what you are doing since it’s a challenging environment. I had it working fine at 1k baud with 5m of unshielded cable with 500 Ohm pullups and 100 nF caps. I’ve noticed most people consider this a hack, but meh. If noise is a problem, then modify the conditions so noise becomes irrelevant.

(if someone tells me something can’t/shouldn’t be done, that just makes me find a way to do it, and do it well J I’m such a rebel!)

 

Paul.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5c2d1abd-0365-4a80-9c4b-b9e0e3b6a38f%40googlegroups.com.

[Paul Kelly]

IR led on the head shining down on a detector in the feeder? Simple, cheap. 

IMHO, the cost with a wired solution is in reliable connectors...

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/SY3PR01MB01710085735816D48EC57A369E170%40SY3PR01MB0171.ausprd01.prod.outlook.com.

[Dustin Kasel]

Pogo pins are a decent solution for temporary connections like this. Design a long interface board with 4 exposed strips of copper and you're good for any width feeder.

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/9ro8WginfI4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7625F25A8EF143B28501E99CF40B61D9%40HomePC.

[Dustin Kasel]

Rob, don't take our comments as discouragement regarding your project and your design preferences. In your specific case it sounds like I2C is a good choice because you have code for it and are comfortable with it. I originally brought it up because any design adopted by the larger community needs to be immune to all kinds environmental noise that even testing to industrial EMC standards may not catch (think of the hacker with an old CRT sitting open on his bench). The reality is you have to over-design these kinds of interfaces when you're deploying in environments that aren't well characterized.

Personally I dislike I2C just on principle. I've had some experience with it and occasionally have to design something where a sensor is only available with that interface. But I find serial to be much easier to debug and USB to serial converters readily available. PCs may not come with serial ports anymore but that doesn't mean their use isn't alive and well. Just about any device with a USB-B connector is probably using a USB to serial converter and communicating through the OS kernel using a COM port.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5c2d1abd-0365-4a80-9c4b-b9e0e3b6a38f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/SY3PR01MB01710085735816D48EC57A369E170%40SY3PR01MB0171.ausprd01.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/9ro8WginfI4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openpnp+unsubscribe@googlegroups.com.

[Robert Walter]

Dustin,

Don't worry, I have a thick skin. So no offense taken.

I don't mind good banter. I always take constructive criticism well, and try to learn from it. In all honesty, I have been quite involved in long distance serial comms for almost 20 years now. Most of which was RS485 / RS422 / Modbus / CAN while doing factory automation jobs. Some stuff up to 1000' or more. All I can say is that almost anything can work very well  when implemented properly. As you said, familiarity can breed comfort in some instances. That is why I will likely start with I2C. It has been the focus of my time lately, and am having some very good results with it.

What I have learned though, is that the key to any good serial comms is both in proper hardware design, wiring,  and also in proper software implementation. It is rather easy to write a serial driver that works on a good / short communications link. It is a lot harder to write one that does not lock up / fail when things get noisy. But in all cases, you can't beat physics. Capacitance and rise / fall times are beasts to contend with at distance / high speed.

It took me a considerable amount of time to get my I2C driver working reliably. I did most of my testing at 100+ feet using the cheapest four wire, un-shielded, non-twisted wire I could find (alarm cable), and kept at it until we were in the 100 million clean packets range at 56K. This was using a differential transceiver though. Yes we could induce errors in the bus, even with differential wiring, but the software could deal with it. Wiring ran all over our offices, including above and below computer workstations, through the electrical room, around the electrical panel, around fluorescent fixtures, just trying to introduce noise and break the link. We have implemented on a few installations now, and zero issues after 6 months, so I am quite happy with the results / performance. But all in all, serial comms is serial comms. You are still sending one bit at a time. The elegance of the electrical and software implementation is what makes it work well.

I have yet to deal with EMC issues on I2C as all of my commercial products transition to differential signalling. This dramatically helps with EMC. I wan't planning on using differential on the initial version of the feeder for the sake of simplicity. But I will see how it all works on the prototype. Maybe I will go CAN / LIN. I don't know. Like I said, I could likely bit bang 1-wire and make it work. I just want to try and use hardware comm module on a low cost MCU as to exploit event / interrupt based processing of the incoming packets. I hate polling for new data!

Anyhow, for me this is more an exercise in creating a unique feeder design, that works really well, with a really simple, low cost parts list. I would love to build $10 feeders, but I don't think the initial quantities will permit it. Unless someone out there has a CNC laser cutter / turret punch that they want to donate some time on. Certain parts will cost a bit to produce, others though should be pretty simple and cheap to make / print.

I hope it works out....

Rob.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5c2d1abd-0365-4a80-9c4b-b9e0e3b6a38f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/SY3PR01MB01710085735816D48EC57A369E170%40SY3PR01MB0171.ausprd01.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/9ro8WginfI4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[mob...@gmail.com]

How big do you have planned the cover tape spools? I have 13mm spool diameter and 10mm clearance.
This allows for 3760 4mm feeds before operator intervention is required.

[Rich Obermeyer]

Robert,

Is there anything we can do to help (other than the laser cutter below)?

Software/PCB etc.

What part of the country are you at?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/af189a3a-0a96-48b9-acbf-8c03bd4bbb5d%40googlegroups.com.

[Maddog]

@Robert,
What happened? Things were starting to heat up and move forward and you go dark!
What's next?

[Robert Walter]

Maddog,

Quiet, Yes. Dark....Not in the least.

Just really busy with work, so I have had little time to spend in the forum. I have been working on the mechanical design, and am pretty happy with the way it is progressing.

I also am doing a conversion on my PNP to smoothie hardware, so not much free time at all. I hope to have the Chinese controller ripped out, and OpenPNP running by Christmas as well.

In reality, the feeder has become a larger project than anticipated, so it is taking quite a bit of time. Lots of little parts... Very finicky, parts. If I were doing things the traditional way, maybe it would be easier, but I wanted to have a somewhat unique design, so everything is custom, but for the most part, can be 3d printed or laser cut.

Hope to have full working prototype done by late December / early January. I will post pictures / video when I have something actually working in the real world.

I do however have most parts designed / modeled / assembled in Solidworks, and most of the design is pretty sound. Of course, real world testing will tell the whole story. Possibly when I get the everything finalized, I will post a animation from Solidworks.

Happy Holidays.

Rob.

[Robert Walter]

OK,

So I am looking for opinions for the feeder electronics. I am debating as to make a single control board with I/O for driving a bank of feeders (8 feeders or more), or to make each feeder somewhat smart and have power and comms to each feeder. In any case, smart feeders are a nice thought, but physical space is at a premium,  and much of the MCU's inputs / outputs are wasted to drive a single feeder. Also, adding serial comms / CAN / etc make for more expensive / larger MCU's. Additionally, wiring / connectors for power + comms and the associated connectors adds more cost. I am really trying to keep costs low.

I am half leaning towards bringing motor leads and sensor leads directly out of the feeder, in order to have all the feeder electronics in the feeder rack (Yes, the feeder / component reel is designed to be easily removed from the PNP). This means likely 5+ pins connector for motor, logic power / ground and sensor data.

The other half of me is thinking of a possible micro MCU (ATTiny85 or similar 8 pin mcu). That way indexing is handled intelligently by the feeder, but a simple 5V pulse will cause the feeder to index  / advance in increments of 4mm (one pulse for a 4mm increment, two pulses for a 8mm increment, etc). This way only three conductors are needed per feeder (+5V, Ground, Advance Input). This makes for really simple interface to a master feeder controller as one output can fully control a feeder. This way serial / usb MCU with a simple program to drive digital ouputs can operate multiple feeders very easily.

The low wiring count also allows for either a very cheap 3.5mm headphone jack connection. I have thought about spring loaded contacts in the feeder rack to make the connections on insertion of the feeder, but my machine has very limited vertical clearance for feeders. It could be done with my feeder design, but I would likely have to modify my Z-Axis to allow for the extra 1/4" of clearance to fit the connections into place. Maybe Version1 will be wired and Version 2 will be spring contacts...

Anyhow, let me know what you think. Right now my design will only support indexing in intervals of 4mm. I don't think I am going to worry about specialty / high density reels that are spacing components at 2mm / 1mm. I just can't see the need at this point. Maybe Rev2 or Rev3 could handle this.  At the moment it would completely blow up my current encoder design. On the other hand, such small feeder increments would be better handled by the PNP alternating between two or more pick positions between advancing the feeder 4mm. Just a thought.

Looking forward to feedback.

Rob.

[Rich Obermeyer]

How were you planning on setting the address of each feeder.

I would think you would want 3 or 4 pins to set the address of each feeder.

Then if the comm is I2C, serial or even CAN the position is determined physically.

I personally would like a RS485 receiver choice because termination is easy.  That may require more address bits.  I hate dip switches because they can have duplicates without knowing and hard to find.  Simple CPU with serial to drive the advance would be trivial and cheap.

I saw all that magic programming to the 16 feeder unit and it too complex for DIY IMHO.  Keep it simple please.

I would think a simple PCB the feeders sit on would work.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/348b7648-1b1f-44b4-a068-78a7dbb5f112%40googlegroups.com.

[Robert Walter]

Maddog,

That is kind of why I am leaning away from the "Smart" feeder with on board comms. DIP switches, albeit cheap in quantity, can be a pain for addressing due to duplicates. Also, I don't think OpenPNP will support feeder slot re-assignent any time soon, so having a feeder address gains no added benefit, as if you put the feeder in the wrong place, the system wouldn't adapt. Yes it would index, but OpenPNP would go to the wrong place for pickup. Maybe a future version could support this, but there are far more valuable features to add in the short term. Ideally, the feeder would automatically get its address from the slot it is inserted in, eliminating the whole DIP switch problem, however this would require at the least, a BCD address set by the connector.

At about $0.50 per pin on spring contact connectors, it is not the end of the world in terms of cost, but it does add complexity to the feeder rack. Somewhere along the build process, an address will have to be physically set to a slot or a feeder. This would then require addressing at the rack level, and still a pain.  With an external rack controller, with plug in cables, addressing is based on an IO map between connectors and the rack controller MCU. A small rack controller could easily handle 8 or more feeders, and could be USB driven and could even have a 485 bus to set rack addresses. This makes life much simple when starting to consider 8mm / 12mm / 24mm feeders.

In any case, not a easy problem to solve. I am just trying to build something simple, at least at the feeder level. Maybe the rack controller adds some complexity in one respect, but at least if a feeder is relatively dumb, problems could be traced easily at the logic level. Grounding out a terminal to cause an index movement is pretty easy to do when problem solving. Haveing 50+ feeders on a 485 bus is no small task though for a electronics newbie. I have spend many a day working on large CAN / 485 / 422 networks, and try to avoid them when necessary. Albeit this would be master slave, so comms would be minimal, any noise picket up in a rack mounted bus would cause grief.

I hope that a good solution can be conceived. Something simple yet elegant.

Rob.

[Cri S]

Add i2c EEPROM bus and Every feeder have either dedicate clock/data/address pin. Just 1 pin.
And if using hw i2c clock out additional cycles manually.

[Graeme Bridge]

My thought would be simply make each feeder autonomous, use a tinyAT to set the component spacing and go back to the original idea of an optic sensor to sense when the tape needs to be advanced.

I admire the enthusiasm to create a high spec machine on a budget but does any one really need this complexity? if your trying to build hundreds of boards an hour then is a home built PnP really a commercial solution? 

[Peter Homann]

On 10-Dec-15 7:04 PM, Cri S wrote:
> Add i2c EEPROM bus and Every feeder have either dedicate clock/data/address pin. Just 1 pin.
> And if using hw i2c clock out additional cycles manually.
>

I'd suggest not using i2c for this type of application. i2c is not a robust
interface ad not well suited to industrial control application. If a
communication bus is to be used, then a differential wiring seems to be a
necessity. RS485 seems the logical choice for this.

Cheers,

Peter

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Anthony Webb]

I agree with Graeme, walk before you run. First make a simple autonomous feeder, once it is proven to have all the kinks worked out (and if the need still exists) you can tackle the additional complexity of making them smarter and coupling them to openpnp directly.

[Robert Walter]

Graeme,

For me, its really not about speed. If I needed to build boards that fast, and in high quantity, I would definitely consider a commercial machine, or in the least outsource the assembly. However, many of our products are low volume, low to mid range component count products for niche markets. I need a feeder that is accurate, reliable, and facilitates tape / reel changes without the risk of knocking other reels / tapes out of position, which are the main issues I have with drag feeders. Drags are cheap and easy, but aren't all that reliable. Jason added a nice touch with the vision inspection routines to accommodate drag misalignment, but a tape jam / hangup can easily cause a machine to lose steps, and that screws up a whole board.

All I really want is a feeder that costs around $30 - $50 to build. Indexes perfectly 99% of the time, and does not rely on a drag pin hanging from the main PNP head. Sure there are independent drag feeders with a separate stepper and drag head, but the web of rails, tape covers and winders makes swapping a reel a major pain. I dread having to change out 10+ reels for product changeovers on our current drag based machine. I find the biggest problem with drag feeders is the inherent vibration that the drag pin induces on the tape it is picking from. I have watched 805 resistors jump out of their tapes and actually land back in the tape upside down. Not a big deal with a resistor, but if it were a diode, a bad board is coming...

I find that the trick to feeder design is three-fold. Density is a #3 to me. It is important but not uber critical. Slim is good. Simplicity is #2. Less parts and gears makes for less backlash / room for error. #1 is stability. Smooth is everything. Proper guides and support for plastic tapes is critical to ensure smooth, vibration free pickup. Paper tapes are far less finicky to support properly, but they do seem to have more issues with overly adhered cover tapes. I guess each tape type has their own unique characteristics. The electronics are trivial. Important yes, but in the end, you are just turning a motor / moving an actuator to create linear motion. The art is in the mechanics. As long as the tapes moves smoothly when the motor runs, getting it to stop at the right place all comes down to a simple, well designed and placed sensor.

In the end, all I would like to have is a pile of feeders in order to change over products without spending hours lacing in tape and tape covers on static feeders. Of course this sounds like a commercial feeder / machine, but $300 - $700 per feeder is currently out of my budget. I plan on building at least 50 to 100 feeders once the design is sound for my own purposes.

The enthusiasm comes from deep rooted issues... But I do like to design things that work well. Hence the time spent so far. Being busy with regular work doesn't help either.

I truly appreciate all the banter. Even if I don't take every bit of advice, everyone who challenges my ideas, I think, makes for better final designs.

Hopefully this works out in the end.
Rob.

[Graeme Bridge]

Rob,

I think a design that used a pancake stepper and a pin wheel like william has in his design controlled by an ATiny for the number of steps which could be adjustable would be a simple solution. this would allow quick setup for the number of steps the motor would need to turn for the component size. 

[Rich Obermeyer]

@Rob,  Your path sounds great to me!

Keep at it and ask for help if you want some. I will help.

I have Altium, Solidworks and a big 3D printer to prototype.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4b224f01-3231-4f68-bc91-4a4fe8939aa7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Rich Obermeyer]

@Rob,

I was suggesting the addressing come from contacts as it mounts to the 20mm bracket.  Little PCB run along the extrusion.  This way when you remove and replace the feeder it always has the right address even if you swapped out the feeder.  This mount would also distribute the RS485 and maybe power to all the feeders at once.  I would suggest 12Volts not 5Volts myself since 12Volts is always there.(unless you use 24Volt steppers)  The 5Volts would have to be generated.   No cables.  One USB to RS485 board would drive the complete feeder assembly so openpnp can advance anything easily..

I see each feeder would have a pancake stepper and cheap micro to run it and take advance commands off the RS485 for as many feeders as you wanted in the pack.  Could be 4, 8 even up to 16 with 4 contacts.

This means the hardware would be very cheap and simple.  Easy to diagnose.

How accurate would the tape position be with that metal tape sprocket and using a direct connect stepper be?

If the sprocket fits well in the tape, do you need more feedback as to where the tape is?

How many pulses to the stepper motor for 2mm tape advance?

Need some way to calibrate it.  After that the micro would know where 2mm is.

--

Rich

[Dustin Kasel]

Wouldn't it be better to just use an 8-bit addressing scheme permanently programmed into the feeder? Then have some type of permanent mark on the feeder that matches the address so that part pick locations can be mapped with feeders. Another option is to have a 2D barcode visible to the camera and have a routine to identify the location of each feeder. Personally I dislike anything that results in extra physical contacts (i.e. address lines).

Dustin

[Robert Walter]

Rich,

I am looking more and more into the whole comms vs I/O triggering. I will ponder it for a few days and see where it lands... In the end, it just needs to work well in the feeder rack.

With regards to direct drive steppers, I am not so keen on the idea. Steppers are not great at keeping position. Especially when microstepping. In any case direct drive is difficult, as to ensure native step angle vs tape index, you want your tape sprocket to be sized specifically such that pin count vs linear travel works out to a perfect number of steps. Otherwise over time you have almost no chance of keeping accuracy. The only real way to make this work is real time encoding of the tape position. If you have that, the need for a stepper motor becomes moot. In any case, I am taking the closed loop servo route (not RC servo). Just a DC gear motor and an encoder and seeing where it gets me. In my opinion, steppers are over rated for feeders. Yes they work well for open loop position control, but only when you constantly track the steps, and also track the rounding errors. It is much easier to track the tape holes in absolute, and then use a motor of any kind to close the loop (position). This way, error can not accumulate, it can only be absolute aside from over / undertravel, but this is typically consistent to the point of high repeatability. This is why most motion control components are specs in both accuracy and repeatability. Getting anything made that is absolutely perfect (such as a ball screw) is nearly impossible (at low cost) , but you can be relatively certain that if you can account for the small positional inaccuracies, and be confident that you can repeat the same movement over and over, life is much easier. Loosing a portion of a step (microstep) here and there due to rounding, mechanical slop, etc becomes a giant hurdle when indexing the same amount (theoretically) of a typical reel of 5000 components. 

I am also severely limited by room for the control board. If I put it on top of the feeder, I have more room to play with, but then I have to bring wiring down to the bottom for connections. A few wires no problem. Bringing 8 pins for addressing + 2 power + 2 Comms makes for a lot connection points. I could go with a FFC cable, but getting the connectors into the limited bottom of feeder area would be a tight fit (may not fit). I only have 20mm of vertical clearance on my machine to squeeze the feeders onto the table. Otherwise the head does not have enough room to clear the feeders! The feeders slide into a horizontal bar at the front of the feeder rack, and pivot down to lock into a second bar at the back of the feeder. Simple and compact, but creates some restrictions for wiring and bottom connections as well. Direct soldered FFC could work but is a pain for a hobbyist to do easily at home. I am allready at the point where leadless mcu packages look attractive for the feeder board....

I would not want to design anything limited to 16 or 32 feeders. So 6 address pins (64 feeders) would be absolute minimum. This is why I am considering smart racks and not so smart feeders. It just puts less weight / wiring on the feeder control, and each rack can be a 485 or similar node that handles 8 x 8mm feeders. You would still have the simple serial command structure, and easy tie in with openPNP, but you could index any one of 8 feeders from one 485 node, vs each feeder being a node.

Currently, I am at 16mm width for a 8mm tape feeder. I have not done a 12mm tape version / drawing, but per the design, it should only add the extra tape width vs an 8mm (so 20mm feeder width). This would only change a few parts in the feeder design. The tape guide, tape hold down, and the cover tape reel width. So in theory, an 8mm feeder takes up one feeder rack slot. Other feeder sizes (12mm / 16mm / 24mm) could fit into two standard 8mm feeder slots in the rack. It would also ensure that connection points are universal for any size feeder.

I don't know, maybe I am over engineering all of this. I am rambling on for sure, but it helps me think....

Rob.

[Robert Walter]

I like the way you think.... Gonna have to consider the 2d code thing....

Rob.

[Rich Obermeyer]

@Dustin,  permanent address means if you move the feeder off one slot openpnp will look for it at the previous spot.

The 2D barcode would be cool but is it going to get done without serious effort by openpnp?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/31aba5dc-37c7-4ed8-bd3c-7dc45e69dea7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Jason von Nieda]

Adding 2D barcode support to OpenPnP is nearly trivial. I did it as a tech demo in a couple hours one morning to show it could be done. I wouldn't worry about it.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAOvy4mYydsGnfxE83F6uKbJOLWhf7t0-ELnH15uZEq47s_AKJg%40mail.gmail.com.

[Rich Obermeyer]

@Jason,

I can see potential but at this point I don't even have a useful feeder other than taping it to the bed..

What support is currently in openpnp for 2D barcode for anything?

Will it verify that the correct feeder is in place?

Will it find the correct feeder?

That routine Dustin was referring to is that trivial too? 

Just trying to find out where we are with this potential.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyRxBuvMMA6-qCT2xvjop-Dv720QO%3Dy1LSzd7vGvGPWyg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Jason von Nieda]

Hi Rich,

That's actually another reason I mention not to worry about it. The software side of feeders tends to be very easy. As soon as someone comes up with a reproducible, repeatable, open source feeder you can bet I'll make sure the software is working for it. But first we need a mechanical design that works and is reliable. 

To specifically answer you questions: None of that is in OpenPnP right now. I added 2D scanning as a tech demo a few months back just to see what would be involved and it was very easy, but it was just demo, throwaway code. The design for feeders, though, makes adding this kind of functionality quite easy. I think we'd take the approach of having OpenPnP know about slots and letting the feeder implementation check what is in those slots. There are lots of ways to do it, and extending OpenPnP to do it is a piece of cake. We just need the feeders first :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAOvy4mbR%3DfdtC97%3Djncxu7ik_p9Q43MFGN_OK-47OohNZD1mYw%40mail.gmail.com.

[Rich Obermeyer]

Jason,

Thx for the feedback.  I feel your enthusiasm.  Let's get it done!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy4E003i0QhqWLDQ9mjcB%3DruuxkpPS4B8aac0YUxvYDag%40mail.gmail.com.

[Rich Obermeyer]

@Rob, How did you come about putting 22 cogs on your tape sprocket?

--

Rich

[Robert Walter]

Rich,

I never said how many cogs are on my tape sprocket. It is a closely guarded secret.....

Just kidding. Tape sprocket is not finalized yet, so I don't actually have a cog count. The count will be small as I am not driving the tape with the sprocket, only measuring position. So I don't get any advantage to a larger sprocket. I think I am at 14 cogs at the moment if memory serves me right.

On another note, I picked up the openfeeder.org domain today, and hopefully will start adding content to a new github project over the XMas holidays, time permitting. I will have renders and basic specs at first. Will move on to full CAD files once design and prototype is functional.

I spent most of this evening designing the feeder control board, and have decided to go the simple route. Just a ATTiny10 with H-Bridge, Encoder, 3Pin spring pin connector for power / ground / feed command, and ISP header on board. Still working on the hardening of the IO so hot swapping is possible. The H-bridge is fed via the pwm output on the microcontroller so variable speed is possible, along with shunt braking of the motor. The encoder will be interrupt driven on both high to low and low to high transitions. I hope to get an accel / decel profile built into the motor routine in order to keep movement as smooth as possible, as well as to increase positional tolerance. I can't see an reason this all wont fit inside 1K of memory.

The reason I ended up going with a 3 pin power + logic based feed signal was for a few reasons.
#1, it is a really simple and cost effective mcu per feeder.
#2, it fits on a extremely small board which easily fits on the bottom of a 16mm wide feeder, and only requires one pair of wires up to the motor.
#3, it can be made to function with as little as a mechanically actuated push button / limit switch to work with any PNP machine.
#4, the feeder rack can be made as smart or as dumb as one wants. I intend to build 8 or 16 slot racks with each rack being a RS485 node, but could just as easily be driven by bit banging...
#5, I want to get this done quickly, and more complicated = more time, and I like spending time with my family too...
#6, 50+ nodes of RS485 with spring contacts does not sit well with me. JMHO
#7, There will be room for improvement (Version 2 in the future)

Anyhow, that is where I am headed. Things may change, as it is all on CAD. Thanks for all the support. I will keep you all posted.

Rob.

[Rich Obermeyer]

Interesting, I counted the cogs off a picture I saw somewhere here. :-)

I was considering that if the tape sprocket had 20 or 40 cogs it would match up well with the traditional 200 step per revolution of most stepper motors without micro stepping.  Making feedback for position very simple and very accurate.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1296de70-09d3-4933-b99e-740242b16120%40googlegroups.com.

[Robert Walter]

Rich,

So far i haven't posted any pics, so you are probably thinking of some other design (there are more than a few floating around here). I am trying to get work done on this project, but paid work always seems to get in the way... :-)

Git-hub repo is up, but I have yet to post any data. I will keep you all posted.

Rob.