Openpnp

[Pixopax]

Hi there, is here someone who uses openpnp with the liteplacer?
Openpnp has now bottom vision, which would make it a lot more usable.
I wonder if someone got it running, as I had problems with the homing cycle, could not get it running.

[l0wside]

OpenPNP bottom vision could solve the rotation issue for finepitch you had mentioned in the other thread. If I understand Jason correctly (https://github.com/openpnp/openpnp/wiki/Bottom-Vision), rotation with bottom vision is supported.

Do I understand you correctly that OpenPNP with the Liteplacer is essentially running, only the homing function does not work as expected?

Max

[Pixopax]

Yes, I had an issue with the homing of Z, Jason made some suggestions on how to overcome that problem, but that did not work.
It drives the Z-Axis down when it searches the Limit-Switch. It should drive it up.
Jason suggested to rewire the Limit-Switch, but that would not change the wrong direction. If you do not stop it, it rams the Z-Axis into the table while homing.

Jogging works correct though. I will give it a new try in a few days, maybe I can change somethin in the tinyG.

[ameli]

Yes, I had an issue with the homing of Z, Jason made some suggestions on how to overcome that problem, but that did not work.
It drives the Z-Axis down when it searches the Limit-Switch. It should drive it up.
Jason suggested to rewire the Limit-Switch, but that would not change the wrong direction. If you do not stop it, it rams the Z-Axis into the table while homing.

Jogging works correct though. I will give it a new try in a few days, maybe I can change somethin in the tinyG.

If the z-axis motor is spinning in the wrong direction from what OpenPNP is expecting, can you just reverse the wiring on one coil pair?

[vonnieda]

Yes, I had an issue with the homing of Z, Jason made some suggestions on how to overcome that problem, but that did not work.
It drives the Z-Axis down when it searches the Limit-Switch. It should drive it up.
Jason suggested to rewire the Limit-Switch, but that would not change the wrong direction. If you do not stop it, it rams the Z-Axis into the table while homing.

Jogging works correct though. I will give it a new try in a few days, maybe I can change somethin in the tinyG.

If the z-axis motor is spinning in the wrong direction from what OpenPNP is expecting, can you just reverse the wiring on one coil pair?

Indeed. Homing is a controller and motor issue, not an OpenPnP issue. I don't say that to sound off-putting, but that is at the technical level how the problem needs to be resolved. OpenPnP can send any homing command you like, so as long as you have a homing command that works for your machine, you just need to use that command with OpenPnP. The first step of setting up any machine with OpenPnP is to discover the Gcode that is required to run it.

OpenPnP currently sends this command for homing with the TinyG driver: G28.2 X0 Y0 Z0 A0

Currently, I suggest using the Gcode driver, instead. This driver is very flexible and you can use any Gcode you like: https://github.com/openpnp/openpnp/wiki/GcodeDriver

Jason

[Pixopax]

I got it working now, I had to reverse the Z-Motor with $3po=1
(Default in liteplacer is $3po=0)

Then, you need to exchange the Z-Limitswitches of the Liteplacer, move the probe switch as limitswitch, and put the Limitswitch as Probe-Switch.
Also, you need to change the tinyG-Settings for the Z-Limit switches to
$zsn=0 (Off)
$zsx=3 (Limit and Reference switch)

(Default is $zsn=3 and $zsx=2 in liteplacer)

Then the homing cycle runs smooth!

Now I have the problem, that the vaccum pump is not able to switch on, so I have to rewire that, not so bad, but you could change that easily to switch the "SPIN"-Output when placement starts.
Also, there is no vacuum probe in openpnp, thats a pity, as it makes placements much more reliable.
And third, most important, I could not find where I can enter tape surface and pcb surface heights, I put that question into the openpnp-forum. If it is there, it is well hidden.

So it runs, but its not placing yet.
What I really like on the openpnp software is the very good vision, much better and faster than liteplacer-software.

[JuKu]

And third, most important, I could not find where I can enter tape surface and pcb surface heights, I put that question into the openpnp-forum. If it is there, it is well hidden.

For others reading this, the question got answered: https://groups.google.com/forum/#!topic ... fPRZ50n2oA

[martin123]

I got it working now, I had to reverse the Z-Motor with $3po=1
(Default in liteplacer is $3po=0)

Then, you need to exchange the Z-Limitswitches of the Liteplacer, move the probe switch as limitswitch, and put the Limitswitch as Probe-Switch.
Also, you need to change the tinyG-Settings for the Z-Limit switches to
$zsn=0 (Off)
$zsx=3 (Limit and Reference switch)

(Default is $zsn=3 and $zsx=2 in liteplacer)

Then the homing cycle runs smooth!

Now I have the problem, that the vaccum pump is not able to switch on, so I have to rewire that, not so bad, but you could change that easily to switch the "SPIN"-Output when placement starts.
Also, there is no vacuum probe in openpnp, thats a pity, as it makes placements much more reliable.
And third, most important, I could not find where I can enter tape surface and pcb surface heights, I put that question into the openpnp-forum. If it is there, it is well hidden.

So it runs, but its not placing yet.
What I really like on the openpnp software is the very good vision, much better and faster than liteplacer-software.

Hi Pixopax,

how is the transition to openPNP going?
Are you placing parts now?

Martin

[Pixopax]

Had no more time to try, currently I use the rmod-release of the liteplacer-software, but changed to my needs.

Also, openpnp has no pressure sensing, I guess I wait until that is included, as I had often mispickups without sensing the pressure, liteplacer-software with Pressuresensor works much better.

[mrandt]

In case anyone is interested; I have openPNP running on LitePlacer.

Few things to note:

• Make sure you install and download and install the "latest" version of openPNP; the stable branch is pretty much outdated
• As pixopax mentioned, wires for Z-max and Z-min limit have to be switched at TinyG
• TinyG configuration (revolutions per mm, speeds, acceleration, homing speeds etc.) is best completed in LitePlacer software
• Afterwards, the following configurations have to be sent to TinyG; either via LitePlacer GUI or using your favourite RS232 terminal program:

  Code: Select all

  $3po=0
  $zsx=3
  $zsn=0
  

  This will invert Z-coordinate (upwards is Z+; downwards Z-) and change the limit switch settings. It disables Z-probing for the time being, as that is not supported in openPNP
• I recommend reading the quickstart and setup and calibration docs:
  https://github.com/openpnp/openpnp/wiki/Quick-Start
  https://github.com/openpnp/openpnp/wiki ... alibration
• Configuration is pretty much straightforward. If you have 1 head (as default LitePlacer does) and do not use nozzle changer, you don't have to edit any config files - so don't be scared
• I use TinyG driver in openPNP, had to change a few minor methods in TinyG driver class to control the vacuum valve without rewiring solenoid and pump
• My USB cams worked without an issue using "OpenCvCamera" driver. No issues with unstable connections, no red Xs - and I even display them next to each other. What's also nice about the camera drivers are the options to set desired resolution, rotation, image cropping, flip / mirror and FPS. There is even a filter for lense distortion which I don't need but might be helpful with certain cameras. I wished exposure and whitebalance could also be controlled via the camera driver; but at least with the Logitech cam you can set these to fixed values using the manufacturer's camera tools.
• As openPNP does not home in on sprocket holes and fiducials (as LitePlacer does, by iteratively centering above the feature) the "units to px" (px-to-mm) ratio needs to be extra precise and measured at the correct Z-level
• This means it is a good idea to bring PCB, tape strips, trays and feeders and focal plane of bottom camera all to a common "workplane" Z-level. In my case I need to elevate the PCB, my modular tape strip feeders are already at same Z-level
• Camera-to-head offset and units-to-px for camera are not automatically measured in openPNP, as in RMOD. You have to manually measure these yourself; it can be done but I guess I am spoiled. The coordinate display of openPNP will show relative coordinates if clicked once, which is a cool feature that allows for easy measurement though
• openPNP does not support nozzle wobble calibration and compensation; so it will not work well with "needles" as nozzle. But with a commercial PnP nozzle such as Samsung or Juki the centricity should be OK.
• openPNP also does not support optical homing; so worn-out imprecise limit switches are an issue for repeatability. I intend to add opto endswitches (like on RepRap 3D printers) to conquer this isseu.
• openPNP does not support Z-probing for heights; so all pickup Z-levels, PCB level and component height have to be measured manually. For most parts, this is one-time effort - but again I have been spoiled.
• PnP data can be imported by simply loading your EAGLE .brd file; worked like a charm. Other ECAD are also supported.
• You will have to maintain a package and part library, which creates some initial effort but has many advantages in the long run. Only configure part height, size, preferred feeder and location and vision pipeline (for bottom vision) once per part, reuse it for all boards. I like that, especially as I try to use common parts across multiple projects as much as possible.
• Once you get used to the UI, it is very intuitive. I miss the keyboard jogging (or have not found the shortkeys yet) but really like the ubiquitious "take cam to nozzle", "take nozzle to cam", "use cam position to set value...", "set nozzle position to set value.." - once you see it you'll like it as well. I also like the job view and pick-and-place list. The status model makes it easy to trouble-shoot and finish partially completed boards. Two sided boards (top and bottom) are also supported; nice.
• To get fiducial detection working, you also have to create a corresponding package (footprint) and part first, once you do it works very nice. There is also a guide on fiducial detection:
  https://github.com/openpnp/openpnp/wiki/Fiducials
• At first glance, the vision algorithms - based on OpenCV - seem to work much nicer and yield better results than AForge in LitePlacer. Fiducial detection (circles in my cas) worked flawlessly under good and bad lighting conditions and even with reflective HASL finish boards - and I didn't have to fiddle with any filter settings.
• IMHO the absolute killer feature is bottom vision assistance for placements. I have only tried some smaller passives so far, but they were detected and placed very accurately. I can't wait to try more complex parts. This will pave the way for placing large parts, ICs and maybe even BGA.

I will keep you posted about my further progress.