--
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/20ac04f3-d322-4ebe-ae87-bdafbe9619c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
well there is prolly a much better way, but my first impression is to extent the "flag" all the way on one side. that way during homing routine if the optic is blocked, move one way to the edge, in open move the other. This will allow the motor to move to a known position then start the homing routine.second option is place the flag so it is at end of travel in one direction.
On Sat, Oct 6, 2018 at 12:44 PM, Shai Schechter <shai...@gmail.com> wrote:
I have yet to set up my machine as I'm still in the design stage but I was wondering after seeing this: https://github.com/Smoothieware/Smoothieware/pull/1349How does openpnp home two nozzles during power up if I use a "lever" mechanism with an optical sensor as shown below? How would the motor know which way to turn so as not to crash one of the nozzles or the lever? In other words, if the left nozzle is already lower, I would want to ensure that the lever doesn't keep pushing it down, but instead turns clockwise.
--
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.
Mike
--
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/ffb8a609-f446-444a-a121-1b193630675e%40googlegroups.com.
It makes the trick if the nozzles are spring returned up. But not if raised with stepper isn't it? Then some kind of homing seems be necessary...
Just as a thought:
If you’re really constructing something new, consider adding Z-probing instead. The all you need to home Z is a flat surface at a known X/Y position. You’d probe Z with both nozzles and the mid-point is zero/home.
Personally I think Z-probing is essential for pragmatic PNP. Otherwise you end up spending a lot of time entering part heights and/or troubleshooting machine table/feeder height imperfections.
Some solutions and ideas:
· The Liteplacer has a proven spring loaded Z axis plus end-switch (I’m using that, see it in action here)
· Mike Mencinger has shown a very nice hall sensor solution (although he is not using it for that purpose)
· I assume you could use Trinamic’s StallGuard™ with their drivers (maybe that’s too slow).
· Personally, if I’d ever construct a head, I’d look into a piezo sensor that measures the stress on some mechanical joint/axis.
_Mark
> Mark does this imply that you probe every time you pick up a part? Something like - move to part location, do a g28 or whatever it takes, go to the zero, pick up the part and set offset.
Marius
Disclaimer: First let me remind you, that this is still only in testing phase. It works very well with sticky tape on the PCB but I have not placed on solder paste. Maybe I will need to slow down probing with paste.
But yes, the probe works for every pick and every place. It just tells the nozzle to go until the Z sensor is triggered. No coordinates involved. OpenPNP never knows the Z coordinate and never needs to know (some relative motion employed, see below).
I don’t need to enter (precise) part heights, a rough Z value one or two Millimeters above the part suffices. The rough value is only needed because I want to move Z down faster than the final probing motion allows.
I solved all this by grouping some of the pick and place steps (i.e. vacuum probing, dwell times, a small relative retract move to better measure the “picked” vacuum level, etc.) from OpenPNP into larger Gcode fragments.
Ask, if I should dig out more details.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e75b8056-2560-4222-9ad4-f91182a1d3d1%40googlegroups.com.
***************************Disclaimer***************************
The contents of this e-mail and any file transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. The content may also contain legal, professional or other privileged information. If you received this e-mail in error, please destroy it immediately. You should not copy or use it for any purpose nor disclose its contents to any other person. The views stated herein do not necessarily represent the view of the Company.
Please ensure you have adequate virus protection before you open or detach any documents from this transmission. We do not accept any liability for viruses!
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/OCEScmV4mic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/56f496e7-a09e-4d0e-8926-ea8202b617d9%40googlegroups.com.