[phomann]

Hi all,

There are 3 files that I see that will be needed, the machine file, the feeder file and the placement file.

1. Machine file. - This contains all the offsets and position plus configuration data for the machine.
For example,

• rapid speeds
• placement speeds
• Machine Home point location
• How many pickup heads the machine has.
• The offsets for each head from the head reference position.
• Where the head reference position is to the machine home position
• Where the feeder bank(s) reference position is
• What vision system(s) the machine has
• The vision machine reference position
• The dump locations where it spits out bad components.
• What component centring systems it has.
• The location and configuration of the centring systems.

Basically, it holds any information about the machine setup that the software needs to know about.

2. Feeder File - This contains information about each of the feeders in the machine.

• Feeder number
• Feeder Type (tape, waffle tray, stick, etc)
• Feeder type info. eg. (8mm, 12mm .. tape) (waffle feeder row col spacing)
• Feeder offset location from the feeder bay reference
• Number of pickup tries (seen very little conversation about recovery )
• Vacuum check required
• Centring station to use
• Feeder label (e.g LM324, 4K7 5%, etc)
• Component height (my P&P doesn't have this as nozzle is spring mounted)

It describes all config data that relats to the feeders.


3. Placement file - defines the following for each Pcb panel;

• Panel reference point location wrt the machine home position
• whether the Panel uses fiducials for adjustment of reference point
• Location of the fiducials
• For each PCB in the panel (for panel with array of pcbs)
• • X,Y offset of the PCB referencce from the Panel reference location
  • flag to skip pcb (for bad pcb, or if the panel is rerun with some boards done)
• For each component to be placed
• • X,Y, theta placement offset from pcb reference
  • Feeder number
  • head number
  • flag to skip placement (Maybe run out of a particular part)

There may also be information in the placement file to define the location for doing a bad board check. This can be checked by a camera to test if any boards in the panel have been marked as bad, and therefore not populated with parts.

There is also other data, but this will get you started.

Cheers,

Peter.

[atlab]

This is an example of my control file in attachment.

[Eclipze]

I really haven't put much thought into the host software and placement file definition. The path that I have been heading down is to use Mach3. Use a script to convert the CAD placement data into gcode, with macro calls. Then define macros for functions, such as nozzle change, pickup component from feeder x, align component etc... But I would rather use dedicated software to manage everything.

I'm not skilled with writing PC software, but interested in contributing to specifications and architecture. The hardware interface is however something that may need some form of standard. i.e. a serial Modbus breakout for the software to interface to machine. I have already designed a Modbus board for my own PnP. However if we all have different hardware, it might complicate the generation of the PC software.

To move forward with creating/implementing an open source system, we will need to become organised and form a development group. Discuss and assign roles in terms of those responsible for certain areas of development and those that directly support those areas. Would this be of interest?

[Eclipze]

I sliced off that depth for the x-axis stepper mount and now it's secures in place as it should. Mounted the stepper and the belt. The belt tensioner is just awesome :-) I'm unsure if or why a spring loaded type of tensioner would be needed. I haven't used one on either belt, but both have the feature to tighten the belt tension via screw adjustment. All feels pretty solid.

Going to work next on the three PCBs and cabling. Still working in the background on how the nozzle change system is going to work and it's implementation. So still a lot of work to be done, but it's really nice to have the x and y axis built and the belts mounted.

[Nails]

I see only very limited usefulness in developing a standard for these files.

If there were an open-sourced machine design with established electronics hardware (motion controller, vision cameras, vaccum sensor, digital I/O), and mechanics (known gear pitches, known presence of limit swithes, etc), then I could see benefit with collaboration on the application software.

However, there is no one machine that fits everyone's needs. Everyone's design goals and priorities are different. And I doubt anyone really wants to give up all the details of their machine, given the amount of engineering time involved.

Making the application software in a generalized way that tries to accomodate all different configurations would be messy, and inherently non user-friendly. I would much rather have a specialized application that shows a picture of the actual machine to show where the feeders are and what components are in them, rather than just "Feeder #12 - 0603 10K resistor". Knowing what is on the machine, such as presence of vision camera(s), dictates how the user-interface will be arranged, as you would need screen space to display the cameras, for example.

[alphatroniqu]

Hi

i make my controller and software for be as versatile as possible
but i cannot put it as totally open source since i use some commercial libraries for modbus
and i put money on it by hiring external programmer

the good news is that i open to any idea for a way to made it semi open source
not for money making ,but for avoid to have some one make commercial product based on my work and of course my money ;-)

the pc side was programed on Delphi so it work whit only one .exe whit no external lib
the firmware side was based on free-RTOS and the motion controller work whit step /dir or even micro-stepping driver for stepper

i may sell pcb kit + software for low cost like maddel do but at very much lower price
but this will lack versatility to have full source code ,and that was need for better work whit all kind of home build machine

Best regard
Marc L.

[atlab]

...but i cannot put it as totally open source since i use some commercial libraries for modbus and i put money on it by hiring external programmer...

Modbus, modbus...
Is modbus really needed to you?
Really a simple protocol is needed with something like RS422 or current loop hardware.
Control command may be:

>99M+88888877<
where 
> - start sign of cmd
99 - address
M - cmd Move
+/- - motion direction
888888 - distance
77 - speed
< - end sign

Therefore, "commercial libraries for modbus" or "external programmer" isn't needed.

[phomann]

Modbus is as simple as it gets. Anything less is not safe or robust.

Cheers,

Peter.

[Eclipze]

Modbus is just a common protocol for automation. You can download the specification for free from The Modbus Organization

I also found in the technical resources free drivers...
"A Modbus library for Linux, Mac OS X, FreeBSD, QNX and Win32 A free software library to send/receive data according to the Modbus protocol. This library is written in C and supports RTU (serial) and TCP (Ethernet) communications. The license of libmodbus is LGPL v3 and the licence of programs in the tests directory is GPL v3."

Either way... you don't need to conform to an existing protocol. I'm using it because it's supported by Mach3 and a good method for controlling additional functions.

[Nails]

A 3 foot rs-232 cable, carriage-return terminated text strings, and some basic error checking is good enough for me.
:banana:

[atlab]

... Anything less is not safe or robust.

You can add LRC to my previous example if you really need in it.
My control module was tested many hours, no errors was detected. Therefore, LRC was removed from cmd.

P.S. Modbus is useful if you use standard industrial modules.
If it not so, it is superfluous and is less convenient.

[alphatroniqu]

HI atlabs

modbus was very simple i have already implementing it on ARR whit 500 byte of code

but i use commercial lib since i have\use already it on other commercial project.
on firmware side it may easy to switch back from commercial to free version of free-modbus , and of delphi side i use modlink but it not really expensive ~150$ usd

also i use modbus since i what to later use modbus-tcp for control all my pick place
from a single pc/program, just like it was one big machine :-)

and remember that i do that project for remplace already working software/hardware
on my 3 juki/zevatech machine that i use for daily production so i build it for be trouble free ,and of course much easy to program that original crappy software in dos.
trust me many time it take more time to program machine that it take for make th production run itself ....(chair) , so data entry must not under looked

Best regard
Marc L.

[Nails]

>>Is modbus really needed to you?
>>Really a simple protocol is needed with something like RS422 or current loop hardware.

Hopefully we can put this to rest. Eclipze has a legitimate reason for integration with Mach3, and alphatroniqu has a legitimate future design goal to switch to modbus/tcp, for better performance without needing to change much in his firmware.

RS422 or current loop hardware is not necessary, unless you plan to operate in very cose proximity to induction hardening equipment, arc welders or the like which produce a lot of EMF, or have a very long run of cable in a conduit along with other switching power signals that would induce noise. RS422 and the error checksums with modbus would be desirable in these situations, but this just isn't going to be the case.

If you are developing your own controller hardware which simply needs to communicate with your own PC software, then RS232 and whatever protocol you choose is just fine. There is no "requirement" to use modbus simply because it is a common protocol used in industrial automation. Use whatever you prefer, and if it is modbus, so be it.

To start another topic, I'd like to see anyone's spring-loaded pickup head design, if anyone has one.

Here's mine. A small spriing (such as from a pen) goes into the nozzle and is held in place with the socket head cap screw with hole in it (shown in spindle.jpg), which makes replacing/changing the nozzle simple. Black magnet pressed onto the spindle holds the tool in place. Not shown is a metal washer that needs to be pressed onto the back of the tool (aluminum), and an o-ring above it to make a vacuum seal against the magnet.

The large red bearing on the bottom, and bearing in the top of head (hard to see) are angular contact bearings, with contact pressure supplied with belleville disk spring washer(s), and secured in place/pre-loaded with the two locking nuts. This should take up any bearing slop and reduce runout.

The rotary union shown is not representative of what is actually going to be there.

[Eclipze]

Do you have a taper on the nozzle mating parts?
How does your stepper rotate the nozzle?
Do you have the vacuum air attach rotate too?

[Nails]

>>Do you have a taper on the nozzle mating parts?

Not totally, there will be a small chamfer/taper on the top of the tool to help start it into the hole. I plan on rotating the head while inserting it to help it, like I have seen someone else do in a video. If needed, I can use the mounted camera to fine-tune the exact pick-up location.

>>How does your stepper rotate the nozzle?
Pulleys and belt.

>>Do you have the vacuum air attach rotate too?
No, the Pisco rotary union I mentioned in an earlier post will be the part that rotates, so I won't have to home, or un-wind the vaccum hose. It is not shown in the picture as I haven't modelled it yet.

[Eclipze]

Looks good! Are you making the rotating nozzle assembly out of aluminum?

[Nails]

Thanks. Yes - Everything aluminum.

[RomanLini]

Thanks Peter Homann and Atlab for the discussion of possible "standard" text files for machine and placement. I appreciate it.

I also think Nails has a point that everyones needs will be different and some people may not be willing to disclose, so it could be a unfruitful project trying to make a standard.


Eclipze-

The belt tensioner is just awesome :-) I'm unsure if or why a spring loaded type of tensioner would be needed. I haven't used one on either belt, but both have the feature to tighten the belt tension via screw adjustment.

Normally the belt tensioner spring is needed to allow for thermal expansions etc. Your metal rail will expand a fraction of a percent when hot, so the options are to have slop when cold (less accurate) or too tight when hot (big wear and load, broken belts etc). A spring is pretty much mandatory on commercial belt driven machines, and you'll never see a belt without one even in crappy little printers. But if you are operating under supervised conditions and constant temperatures etc you can go without a spring and maybe give it a tweak every now and then.

The spring does not have to be complex, you may be able to stick a piece of rubber between the adjustment screw and whatever it pushes on, to provide some spring effect there.

[Nails]

Yes, Peter's list was VERY well thought out, and many things he mentioned was exactly the same things I knew I would have to keep track of, plus a few I hadn't thought of yet. I will be revisiting that post when I start my software. Thanks! To those of you without much automation programming experience, considering all this information up front will prove extremely valuable. He also has a valid point he mentioned about error-handling.

I do automation programming professionally, so I have a few things to say about error-handling. About 15% of my programs have to do with the actual normal operation of the machine. The rest is the user interface, and possibly 25-50% is error detection and display of the error to the user, and mid-cycle recovery handling to get things back on track when things don't go as expected. Some of these things to check could be that a move didn't complete within a certain period of time, an encoder changed state illegally from its previous state giving a corrupted position, a servo/stepper amplifier fault input triggers, the motor's actual position is outside an acceptable window of its commanded position, actual velocity or acceleration is not as expected (for servo motors), the velocity or acceleration you sent to your motion board is ZERO and will never move, you can't find a fidicual with the camera within a certain boundary and requires user-intervention or manual centering, vacuum didn't come up to the level as expected indicating part is not on nozzle or no parts left in your feeder, the vaccum didn't release quick enough indicating a sticky solenoid valve. It can be seemingly endless. It is simply unacceptable for me to have a program I write for a customer "hang" indefinately, requiring them to kill the process and re-run it and have no clue as to what is malfunctioning. Worse yet, is having the machine crash and cause damage. I've gone so far as to show videos walking from the front of the machine to the part in question, so the user knows exactly where the part that malfunctioned is located, rather than just simply naming the error and requiring the technicians to have some level of expertise to understand what the error message is referring to. You can't have your program assume everything will always work 100% perfect every time without any error checking (at least not professionally). If you have the provisions on your machine to check for any kind of error, you should check for it. Even if it is your own personal machine, it will make your life much easier, especially down the road when you don't remember all the details like you once did. If your software can tell you what it found that it didn't expect, it is 1000 times quicker to troubleshoot the hardware defect than trying to diagnose it by running under your development environment, HOPING the problem is re-creatable, so you can hit ctrl-break, single step through your program, explore variables, etc, to figure out what the problem is. That's my 2 cents worth of error detection talk from actual experience.

For what I have planned, the text files aren't the way I need to go. I'm going to use SQL Server rather than text files to hold various tables of information. This lends a lot of flexibility.

For example, when changing over for a different board, rather than having the job dictate which feeders are required to be loaded with particular parts, I can search for the parts required for the job that aren't already loaded on the machine, and only deal with loading what is required. The feeders which already contain parts necessary for the job would be highlighted, and you'd just click on a feeder that was empty, or non-highlighted one to use until your part list for the particular board was emptied (all parts accounted for and loaded on the machine). Doing this via the the user interface eliminates manual text editing, and errors from such manual editing. Even if you do use text files, I would suggest only manipluating them from within your application program.

As another example, as the name of a part is not a hard standard, and each user's board design can define a different component label name for the same or compatible part, I plan on having the ability to indicate that a particular feeder contains a compatible part, and automatically build up tables of aliases for known compatible parts. This will minimize set-up time, but requires a database.

Also, I thought it might be strategic to locate some of the most common parts in two different locations on each side of the machine, and calculate which path would be quicker on-the-fly, rather than a hard-coded pick-up location.

I know this is a lot of "extra" work, but changeover time, minimizing run-time, and user-friendliness is what I am going for.

Of particular interest in Peter's post was:
"Component height (my P&P doesn't have this as nozzle is spring mounted)"

I still don't know why you don't need component height. What do you do when you are mounting stuff like a RJ45 jack? Does your nozzle really spring back a half of an inch (or more) when it places this part?

This is why I posted my pics to share. Even though I like my design, I am still open to learning something from seeing someone else's. Do you have any pics, Peter?

[alphatroniqu]

Hi Nails

Component height was need since if you push part into past part will move
that even if you have a hard vacuum so tick was to release part whit just a very lite pressure into the past ,this also may avoid to breack delicate part but i never see my self that issue

but for part shifting i have well documented the issue whit help of hight speed camera
ADD Component height was one of the project goal of my zevatech upgrade
since original design even if it use slide tube and have very delicate pressure on part
it still have part shifting issue

on another tote on my soft i use a .ini for hold last part used on a feeder so next job look that table for autoplace reuse part that really good for decoupling cap and part that have hight reuse rate

Best regard