LitePlacer.com forums

chorizo wrote:mrandt, can you elaborate on how you modified the TinyG driver? Are these just changes to the machine.xml file, or is it deeper in the software?

I've been trying to make OpenPnP work with my LitePlacer, and so far I have everything but the vacuum valve control working; when I run a short script to have the needle drop down and pick up a component that I have placed directly beneath it, the valve opens before the machine moves, similarly when I tell it to pick up a component then drop it, the valve opens and closes before the machine has a chance to move. Did you run in to the same problem?

Index: src/main/java/org/openpnp/machine/reference/driver/TinygDriver.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/main/java/org/openpnp/machine/reference/driver/TinygDriver.java	(revision 4ca13e6735c77c30d22809679a80199807ff4c6d)
+++ src/main/java/org/openpnp/machine/reference/driver/TinygDriver.java	(revision )
@@ -203,12 +203,15 @@
 
     @Override
     public void pick(ReferenceNozzle nozzle) throws Exception {
-        sendCommand("M4");
+        sendCommand("M4");  // m4 enables pump on LitePlacer (spindle)
+        // HACK
+        wait(1000);
+        sendCommand("M8"); // m8 enables vac valve on LitePlacer (cool)
     }
 
     @Override
     public void place(ReferenceNozzle nozzle) throws Exception {
-        sendCommand("M5");
+        sendCommand("M9"); // m9 disables vac valve (cool)
     }
 
     @Override
@@ -220,7 +223,7 @@
     @Override
     public void actuate(ReferenceActuator actuator, boolean on) throws Exception {
         if (actuator.getIndex() == 0) {
-            sendCommand(on ? "M8" : "M9");
+            // sendCommand(on ? "M8" : "M9");
         }
     }
 

Need to send the "right" GCodes to TinyG. I just quickly hacked the driver; need to fix it properly at some point.

JuKu wrote:Also, Jason said, that " TinyG users can use the GcodeDriver as far as I know". https://groups.google.com/forum/#!topic ... -TAyyZ9XQ0, last few messages.

sebastian wrote:I created a machine.xml that makes OpenPnP work with my liteplacer out of the box (no need to run liteplacer software first to program tinyg or send custom gcode to the tinyg):
https://wiki.apertus.org/images/d/de/Machine.zip

It configures tinyg at connection/startup and also activates pump and valve on pickup/place.

Feedback appreciated.

More details about the development procress: https://wiki.apertus.org/index.php/Lite ... nPnP_Setup

Flavor wrote:

sebastian wrote:I created a machine.xml that makes OpenPnP work with my liteplacer out of the box (no need to run liteplacer software first to program tinyg or send custom gcode to the tinyg):
https://wiki.apertus.org/images/d/de/Machine.zip

It configures tinyg at connection/startup and also activates pump and valve on pickup/place.

Feedback appreciated.

More details about the development procress: https://wiki.apertus.org/index.php/Lite ... nPnP_Setup

I'm really interested in this, so my feedback (for now) is: Excited!

When we can try it, then I hope to have even better feedback.

mrandt wrote: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.

mrandt wrote:Hey Jason,

thanks for posting this update.

I have actually been using the GCodeDriver for a while now and am rather pleased with it. It was very easy to add the commands for vacuum etc. to the configuration.

Once I find the time, I will post my machine.xml here - but I guess I need to add some comments first.

I will also try visual homing and vacuum sensing but the latter will probably require a hardware change to my TinyG.

Best regards - and happy new year
Malte