--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f1713243-6e84-457a-add1-58da80fd5258n%40googlegroups.com.
> Is the idea to then use this to integrate auto focus camera or is that wishful thinking? ;)
No, the camera is a normal fixed focus ELP. The "Auto-Focus" is
done by the nozzle Z, it brings the nozzle tip point into focus
perfectly, then setting the camera Z (which will make sure it is
used for all bottom vision in the future).
_Mark
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/dBg7txMB0R0/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/fcae0ddd-5a01-499e-8c79-81c03224fc96n%40googlegroups.com.
Or did I misunderstand you?
Nozzle driven Auto-Focusing is already used to learn part heights, if that is what you mean:
https://github.com/openpnp/openpnp/wiki/Up-looking-Camera-Auto-Focus
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/940666ae-2f9f-d986-53ce-dee2b006165a%40makr.zone.
> My thinking was auto focus for different heights for the
downward looking cam.
Well, within reasonable Z distances this is not needed. As you
see (in the video) the secondary fiducial is quite blurred, but
not a problem to recognize, if you are using my Circular Symmetry
stage:
https://youtu.be/md68n_J7uto?t=81
This also works for other "probabilistic" stages, like Template Match. Using these, I see all simple feeder (sprocket hole) and nozzle tip changer vision applications covered. Precision applications like visual homing and sophisticated feeders with OCR/QR codes etc. should really always use PCB surface level Z.
The important thing for simple "on top of surface" feeders etc., is to get the Units per Pixel right, dependent on feeder pick Z (for instance). And that's coming soon! 😎
Btw. the underlying 3D Units per Pixel work was done by Tony
Luken, so this will mostly be his merit!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/957b1695-a02f-4146-9fea-f02dfebad5d3n%40googlegroups.com.
Forgot the link to the Pull Request with extensive description
(sorry about that):
https://github.com/openpnp/openpnp/pull/1248
See also:
https://makr.zone/openpnp-automatic-machine-calibration-with-issues-solutions/676/
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f5367164-078c-437d-b15a-fb28f5736fcfn%40googlegroups.com.
Mark, this looks fantastic. It must have been a huge amount of work! I am looking forward to implememting it. I have a question: Does it require auto-focus camers? Mine are fixed focus.
Best, Jim
From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of ma...@makr.zone
Sent: Saturday, August 14, 2021 5:18 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] Re: Automatic Machine Calibration using Issues & Solutions
Forgot the link to the Pull Request with extensive description (sorry about that):
https://github.com/openpnp/openpnp/pull/1248
See also:
https://makr.zone/openpnp-automatic-machine-calibration-with-issues-solutions/676/
_Mark
Am 15.08.2021 um 00:01 schrieb ma...@makr.zone:
Hi,
I've made the Pull Requests and merged/deployed it as a testing version.
For those who haven't seen the video yet:
Important: this is not yet officially accepted into OpenPnP, it is still to be discussed with Jason (@vonnieda) and others and may need changes.
So if you try this out, be sure to save a backup of your machine.xml from before the upgrade and be ready to go back!
Download here:
This will need some broad machine spectrum testing, who's helping?
😃
Thanks!
_Mark
On Friday, August 13, 2021 at 1:19:03 AM UTC+2 ma...@makr.zone wrote:
Hi all
I've uploaded a video of the Automatic Machine Calibration using Issues & Solutions that I'm working on:
This is mostly done and tested on my machine, but I still have to parcel out the Pull Request(s), so it will take some time before this pops up in the OpenPnP (testing) version.
What do you think? ;-)
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f5367164-078c-437d-b15a-fb28f5736fcfn%40googlegroups.com.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1945ea9a-421d-550b-d19e-67d6ea7a63ea%40makr.zone.
Jim,
thanks for the praise.
> Does it require auto-focus camers? Mine are fixed focus.
No special camera needed, the "auto-focus" is not done by
adjusting the lens, but by moving the subject i.e. the
nozzle tip in Z.
It determines the focal plane i.e. the Z coordinate, where the
bottom camera sees the subject most sharp (highest contrasts
observed). It then sets this as the Z coordinate of the camera
position.
Later, when parts need to be aligned, or nozzle tips calibrated,
those will be brought to exactly that Z height.
Btw. there is already an automatic part height detection in
OpenPnP for some time now. Read more about this here:
https://github.com/openpnp/openpnp/wiki/Up-looking-Camera-Auto-Focus
_Mark
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/dBg7txMB0R0/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/085801d791d3%2400b3cf70%24021b6e50%24%40gmail.com.
Hi Mark,
backlash compensation issue and solution stops with an error, see attached screenshot.
Nozzle offset calibration doesn't move the nozzle down so the confetti never moves. Do I have to set the nozzle at confetti Z before?
Have a nice day
joël
--
Just in case, the backlash autosetup log.
Thanks
joël
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/961ec7ac-9bb0-9713-345c-c679eb9d19fe%40makr.zone.
Hi jdlv,
Thanks for testing! 😄
There are two issues:
I will fix these bugs as soon as possible, until then please
press "Find Issues & Solutions" after each solved solution.
Again thanks everybody for testing! 👍👍
_Mark
I suspect you need to move your calibration fiducials farther away from the edge of your machine so that there is room to maneuver around the fiducial. Make sure you place them such that you can jog the camera and see the fiducial in all four corners of the image without running into any soft limits/limit switches.
On Tuesday, August 17, 2021 at 1:32:50 PM UTC-5 jdlv...@gmail.com wrote:
Just in case, the backlash autosetup log.
Thanks
joël
Hi Mark,
backlash compensation issue and solution stops with an error, see attached screenshot.
Nozzle offset calibration doesn't move the nozzle down so the confetti never moves. Do I have to set the nozzle at confetti Z before?
Have a nice day
joël
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c27d417d-e3cc-48f9-b455-e09f1a1a9bebn%40googlegroups.com.
I might add, that some of this may be due to you probably not
following the Milestones. You're probably already at Milestone
"Advanced" with your already setup machine. Therefore, the
Milestones all appear "heaped up".
A user with a fresh machine will instead move up Milestone by
Milestone and these "premature" solutions will not appear. Still
I'll try and insert a dependency check, because I guess this is a
realistic situation.
If you want, you can switch back to earlier Milestones to check
this out:
https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions#milestones--tracking-progress
See the Outline here:
https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions#the-milestones
Btw. Wiki feedback is equally welcome.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8c6f424f-fa28-31cc-f36c-3c88ae92b33f%40makr.zone.
the test rig is in the middle of the working area, more than 400m
away from the X limits. The log shows this just before the error,
the last 2 moves:
2021-08-17 20:25:47.923 AbstractHeadMountable DEBUG: Top Camera.moveTo((433.867017, 191.759117, 0.000000, 0.000000 mm), 0.25)
2021-08-17 20:25:47.924 AbstractHeadMountable DEBUG: Top Camera.moveTo((-5.142914, 191.759117, 0.000000, 0.000000 mm), 1.0)
at X = 433.867017 the camera is where the fiducial is, -5.142914 is far away and more than the 120mm required.
Pressing "Find Issues & Solutions" after each solved solution helps a lot! Camera - nozzle offset is now calibrated.
Thank you for your great work!
joël
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/40689ef8-1924-ae81-5d42-e1e9d268352d%40makr.zone.
Hi joël
> the test rig is in the middle of the working area, more than 400m away from the X limits.
Finally found it.
Background: As part of the calibration it will move right to/from
the soft limits (maximum possible move). It needs to convert raw
axis coordinates (soft limits) to camera coordinates. And that's
where the bug lay dormant.
You seem to have head offsets on the camera that are non-zero,
which is unusual but perfectly legal. This flushed out the
bug, my code was not accounting for the head offsets.
--> Fixed the bug. It will be in the upcoming version.
Unfortunately there is no workaround, unless you want to set the camera head offsets to all zero.
May I ask, why yours is non-zero?
Again, many thanks for helping with this!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8535fb70-3554-9bb9-fa15-afac11c01a48%40gmail.com.
Good catch!
This was initially only offered when you are in the Welcome
Milestone.
But then I made it fully revisitable, i.e. you can change the
solution any time later. But of course, then it needs to discover
the machine configuration, on the very first incarnation.
I've now implemented that. This now also sets the solution as
initially solved on machines that are already beyond the Welcome
Milestone.
It discovers your machine.xml as follows. Note, how it is marked
"Solved" and you have to enable Include Solved to see it:
You could now at any time press Reopen it and then change the number and configuration of your nozzles, without losing any existing settings (except names). For instance if one day you add two more nozzles 😂
Thanks!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/201e995b-be01-4cb1-9eb5-f679e8d418dbn%40googlegroups.com.
Hi Mark,
no problem to wait for the next version. My machine has closed
loop servo and linear scale so the backlash should be very low.
The camera head offset became non zero when I changed the camera for a color one. Didn't have the courage to re-calibrate everything or so, camera offsets was a handy workaround...
I did calibrate the camera - nozzle offsets and then the
uplooking camera position. Everything went fine but now there is a
placement offset when doing a real placement job. Something like
100µm and 50µm on X and Y axis.
Cannot say if the error offset comes from the nozzle - camera or
the uplooking camera calibration or something else I missed. I
tweaked the up camera offsets to compensate.
Would it be possible to use a real part instead of the confetti,
a part that can be seen and aligned by the 2 cameras?
I did a few tests to evaluate the camera - nozzle offset
calibration accuracy;
Successive calibration offsets are subtracted from the first
calibration offsets at machine power up, difference is plotted in
µm. Sorry the sampling frequency is not constant at all and maybe
the Y value at measurement 7 is wrong, previous values entered
instead of new ones (wrong line). Nevertheless it seems to show a
drift over time, maybe the camera self heating?
If the seventh Y value is really a mistake the delta of 2 consecutive value is rather low, my machine has 10µm resolution linear scale. I did not use a confetti but a printed fiducial, a black circle with a 1mm white circle at the center. Don't know if a small circle is better or not.
I will do this again to know if the drift comes from the camera
warm-up or not.
That's a great tool, thank you Mark!
joël
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f3e2e1d8-77b3-aaae-98ea-38468f404c52%40makr.zone.
Hmmm... difficult. I'm no Java Swing expert, just trying my best.
AFAIK, only JLabel can render HTML text and there is no way to
make this selectable.
So I made a hack: you can press the right mouse button and it is
copied to the clipboard.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9b53c9c8-f1dc-4088-a600-24156c10bf47n%40googlegroups.com.
Hi joël
The question is whether it will go on growing. As long as it is
<= 50 µm, I don't see a problem.
It could also come from the nozzle mechanics, there are hot steppers heating the whole head assembly.
If I'm not too tired to get this right:
Aluminium has a CTE of ~24E-6/°C, so with say a 20° to 80° = 60°
heat-up you get 0.00144 parts expansion. With say 70mm offset you
get ~100µm. It may be less heat-up in the aluminium (gradient) but
it may also bend the nozzles out with some leverage because the
front is hotter than the rear.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2a5d2691-3831-7fe9-a4b8-eb95d16e8f8a%40gmail.com.
Done.
It can now be up to 40% of the camera smaller dimension, before
only 25%.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7c6ca572-4e13-47d2-ab0f-02430b58a28fn%40googlegroups.com.
I did the same tests and today the drift is gone, very good and consistent results:
As the previous plot, successive calibration offsets are
subtracted from the first calibration offsets at machine power up,
difference is plotted in µm.
No more drifts, strange... Maybe a mechanical issue somewhere...
Did the same for up looking camera position. If I have understand
correctly the calibration Z height is determined by auto focus.
Looks like the results depends a lot on initial nozzle Z value
something like 1 mm lower. So the initial height value was reset
to the same value of -26mm before each calibration tests:
delta X | delta Y | Z autofocus |
Rotation |
-2 | -3 | -27 | 0.147 |
4 | -15 | -27 | 0.159 |
5 | -18 | -27 | 0.152 |
9 |
-6 | -26.9 | 0.176 |
8 | -9 | -26.95 | 0.142 |
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/55846be4-0947-7125-0123-d98dcfe06c89%40makr.zone.
Auto focus has much less resolution than anything else and
accuracy is (luckily) also much less important, as the focal depth
of the camera is not that shallow and the pick/place Z are not
that important, having a spring on the nozzle.
The autofocus has a resolution of 0.05mm, it will not even try
something more precise. Given that, your results are very good.
There is something that I want to improve one day: today it seeks
for the focus up and down, so backlash will be present. In the
future it should only seek moving down, because all
movements that matter are down anyway.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/059579b1-4835-b1c4-cc3e-b808e24570e3%40gmail.com.
> I tested this new "Testing" release, I did not find any big issues and everything was clear and simple to me.
Cool!
> The only minor issue I found is after N3 and N4 (camera to nozzle offset), C3 and C4 stay on -30deg
The final C rotation of the nozzle is not reset after doing the
calibrations, so this could well be.
I will rotate them back to zero, to allay any concerns that this
might be a "result" of the calibration.
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/70892780-d58c-44b1-9982-6e29c3dfe7fdn%40googlegroups.com.
Hi,
Please help with testing, everybody! 👍👍👍
Another small update in the testing version, and merged the latest contributions by @doppelgrau:
https://github.com/openpnp/openpnp/pull/1262
It just bothered me to let the user manually fiddle with that fiducial diameter. This stuff is supposed to be automatic! 😅
So there is now Auto-Adjust! It might not work every
time, so there is still the manual option.
More info and links:
https://makr.zone/openpnp-automatic-machine-calibration-with-issues-solutions/676/
Please help with testing, everybody! 👍👍👍
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b497055a-effb-7323-799d-56ce1d607ac6%40makr.zone.
Thanks Zdenko, for you ongoing testing! Much appreciated! 😃💯
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c977e62a-8c20-4df2-be1e-284358aefbf8n%40googlegroups.com.
Hi Tony,
Thanks for the thorough examination.
Re 1: Yes, this also accidentally happened to me. But I
haven't found an easy way around it without cluttering the GUI and
making it overly complex (you've probably seen the discussion
feed-back, it really needs to be simple).
Any good ideas? The best idea so far was to add a confirmation message box, asking "Reopening <name of solution> will possibly invalidate dependent calibrations. Are you sure?"
Btw. I spent a lot of effort to make calibration steps as
independent as possible. Examples: X, Y re-calibration will
carefully preserve Z. And vice versa, setting the rough nozzle
head offsets and Z by manually jogging the nozzle over the
fiducial, will preserve calibrated X, Y if those are within
tolerance (within the fiducial radius). Setting new (default)
nozzle head offsets will be propagated to dependent settings, such
as the bottom camera position or an actuator (e.g. Push-Pull) that
was on the same offsets as that nozzle.
So redoing a calibration even out of order is not that bad
anymore.
Re 2: True. Up until now I wanted it be as simple as
possible i.e. handle Visual Homing the same way, where the
standard pipeline expects a bright on dark fiducial. However, now
the Visual Homing solution does replace the FIDUCIAL_HOME
pipeline too, installing one with
DetectCircularSymmetry, so this can go away.
I will change the description.
Re 3. Good remedy. I trust a user would be reasonable
enough to see that a very close limit would really degrade the
results. Do you think the limiting should be limited😉?
Re 4. Well, there are some machines that have pneumatic
nozzles (only up or down). They have a Virtual Z axis and actuate
the pneumatics via Safe Z threshold. Those would be unnecessarily
excluded:
https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator#pneumatic-nozzles
Note: I'm not saying that all the other solutions of the
calibration support such a machine, I just want to avoid
exclusion, where it is unnecessary.
Re 5. You're right. But there's a reason.
My ongoing work on the next round aims to deploy 3D
calibration to most of the various feeder classes, nozzle
tip changer, PCB fiducials (if someone has their PCB not at
default Z, despite all recommendations to the contrary). In order
to do that, I had to examine all direct and indirect (!) uses of
Units per Pixel in the whole of OpenPnP. After working through all
that, I concluded that bottom camera 3D calibration has no use
case. The subject can either be brought into the focus plane
(nozzle Z), or the focus plane is unknown (Auto-Focus).
Therefore, I have now already moved setting the "working plane Z"
fully to the (virtual) axis Z of the camera and removed stuff from
CameraView that allows setting it independently. As it has no Z
axis, this implicitly excludes the bottom camera from having a 3D
"working plane Z".
If we ever find a real-world use case for 3D calibration in the
bottom camera, we will have to find a way of "registering" the
currently viewed subject movable (nozzle) with the bottom
camera and then use the subject movable Z axis
(but sometimes minus part height?) as the working plane. But it
does not make sense, I see no such application. Do you?
So I excluded 3D calibration completely for the bottom camera.
Yes, we could do it, it would even be easier with the
movable Z subject, and my programming is all prepared for it. But
No, I don't think we should. It just makes things more
complex with no gain.
I hope you see that too, acknowledging you must already have spent considerable time and effort implementing it 😕
What do you think?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3b1ee34b-4664-4bec-a24b-c436bcffc40cn%40googlegroups.com.
Afterthought, just to be clear: if you need to preform 3D
calibration anyways, to determine camera tilt and the "true
center", there is nothing standing in its way. I would just not
expose it to the user.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0f0ba43c-0a0c-87bc-af44-2b5952d8fc77%40makr.zone.
Hi Tony,
> The second is not defined anywhere so I'm defaulting it to the Z coordinate half-way between the first and zero with an option for the operator to change it if its not in good enough focus - does that sound reasonable to you?
By "zero" you mean Safe Z, right?
When I was still planning it, I thought I would choose these:
Za = Camera location Z (which is what the auto-focus calibrated)
Zb1 = Camera location Z + the Max. Part Height, as set on the Nozzle. This is also what the Auto-Focus uses as its search-range, when the part height is unknown and must be auto-learned. See the Wiki.
Zb2 = Camera location Z + the diff between primary fiducial Z and secondary fiducial Z, under the assumption that this gives us the useful Z range for this particular machine (maximum practical part heights, etc.) that are equally sensible for the bottom camera.
Zb3 = Safe Z minus 0.01mm (to make it outside the Safe Z zone)
And then:
Zb = min(Zb1, Zb2, Zb3)
But that's probably overkill.
Perhaps Zb1 is sufficient and if need be, it can be
easily changed by the user, on the GUI. Using a LengthProperty,
you can easily expose the Max. Part Height field directly
on the solution. See the backlash calibration acceptableTolerance
for an example.
_Mark
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/dBg7txMB0R0/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/a52f512b-d953-4ae0-91e9-5c6a971e64ebn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/67d86bef-dcb9-b176-e206-ba7916ae94e7%40makr.zone.
Yes, absolutely. Many brains are so much better than just one or two. 😉
The problem: you would have to have different known height test parts (spacer + fiducial on the underside) on the nozzle, to be able to calibrate 3D.
So this would be a non-trivial addition. I guess we have to keep
this in mind for later.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNy%2BdQXqn6WTcMvhqmX4Lq8aRM7Zp4HJSO4iXNSfLGDBdg%40mail.gmail.com.
Hi Robert,
these I&S suggestions show up when you haven't changed the feed-rate, acceleration and jerk from the defaults set (or migrated) by OpenPnP.
Most machines can be optimized to use a different setting for
feed-rate, acceleration and jerk for each axis individually.
On a typical portal style machine, the X axis can be faster, as
the head is much lighter than the whole portal moving in Y. The
accelerations (jerk) are very important for the overall machine
speed.
Even more important, the rotation axis can often be dramatically
made faster in number terms, as these are degrees, not
mm. It is on most machines much easier to rotate a nozzle by 180°
than it is to move an Y axis by 180mm. So you can and should tune
your settings up!
However, you always need to consult your controller's settings.
These limits are often in addition to what OpenPnP sets.
OpenPnP settings must always be lower than or equal your
controller's settings.
As to TinyG's settings, I hope Tony can answer you. You might
search this group for other messages by Tony, he has repeatedly
posted his config, as far as I remember.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/83093f51-2432-428c-b903-ea911dfb95fan%40googlegroups.com.
Hi Robert,
You still need to set accelerations too, even if TinyG itself
does not use or support such a thing. OpenPnP will instead predict
the motion ramp and then reduce jerk, if the set
acceleration limit is reached. So the jerk limit will effctively
be set dynamically, depending on how far a move is, i.e. how long
the jerk can increase the acceleration.
Note, you can look at what OpenPnP does, here (you'll need some Advanced configuration, offered by Issues & Solutions):
https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0fab82cc-e8b2-46b2-98f8-a089b4893912n%40googlegroups.com.
Robert,
Does Issues & Solutions not say anything?
I guess you still have a feed-rate limit on the driver. But again, I&S should tell you so.
A bit of background:
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c72c52f2-e8c3-4c6f-821e-1af90da32999n%40googlegroups.com.
Yes, but let I&S take care of it. Just go to the "Advanced" Milestone.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/55b04963-d2a9-4a55-987d-8391b5f8190bn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9a89eca6-62c1-a870-7b22-44430ddfa04e%40makr.zone.
Hi Saito
The only thing that comes to mind is camera settling. You seem to
have fixed time settling (no settling log entries) and an
extremely short settle time of ~40ms:
2021-09-07 15:53:26.819 Scripting TRACE:
Scripting.on Camera.BeforeCapture
2021-09-07 15:53:26.863 Scripting TRACE: Scripting.on
Camera.AfterCapture
2021-09-07 15:53:26.864 Scripting TRACE: Scripting.on
Camera.AfterSettle
Please investigate, if a (much) longer camera settling time
helps. The fact that it seems to fail in "Random Move Accuracy
Test" hints at some camera vibration/lag issue, related to harsh,
fast moves.
For more info, also about configuring adaptive settling, that
waits longer when the machine vibrates, but is still fast when
not, see here:
https://github.com/openpnp/openpnp/wiki/Camera-Settling
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAH6K8ZXHKEdbSkNq9ssodTc%2BsNaiGcq4KNCWrNHhK3fEWD%3D0gQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e2ecbfb-3640-af41-9fce-8124ebec27a1%40makr.zone.
Hi Saito,
Thanks for testing!
> It is difficult to judge whether this setting is appropriate or not because I don't know enough about each parameter
I guess you've already looked at the WIki? To improve it, please
say where it is not understandable, then perhaps I can improve the
instructions:
https://github.com/openpnp/openpnp/wiki/Camera-Settling#advanced-settle-methods-and-diagnostics
> I noticed that the "Absolute" value of "Error at step" was accumulating errors in a linear pattern.
That red absolute error looks like I made a mistake in one of the
last revisions. I will have a look tomorrow.
Your backlash values look very nice, but the end result is
strange. The orange dots (in the first graph) are the random move
test, that is done at the end with the new calibrated settings.
These show errors of ~0.2mm, which is too much. I don't understand
at all.
Can you please send a log?
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/dBg7txMB0R0/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/CAH6K8ZWtZzfYLy%2Bdg1hxSuEq8ThGi03Nx9uaEoXOtb_35%2B3Y4Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/07eeee6a-337c-e8fa-2dc3-d37830d9fb63%40makr.zone.
> It seems that the units of the parameter you specify for "Center Mask" are not clear.
Fair point, I tried to improve the description:
Use the Center Mask to remove unwanted image peripherals that might spoil Contrast Enhance (like a diffuser or shade partially in view). If set to 0.0, no mask is applied. Values larger than 0.0 are relative to the camera dimension, i.e. 1.0 means from edge to edge. You can set values larger than 1.0, the circle will then be partially cropped.
https://github.com/openpnp/openpnp/wiki/Camera-Settling#advanced-tuning
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAH6K8ZU10BFT0Vhd3Vj6H66kW3LUPEmk2x9dNDZE8frhO6U1QA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ab07209d-86fc-c732-0ae7-2d7611270290%40makr.zone.
> I still can't figure out what causes the "no data" message.
The calibration graphs are only a nice feed-back for the user, it
is only available momentarily until you exit OpenPnP. That's
normal. We would have to implement persisting that graphical data,
but that's not quite so easy.
What is important is that the result of the calibration,
i.e. the backlash method, offset, speed, and
sneak-up distance are persisted and that is the
case.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAH6K8ZWqcAU82%3D%2B1XOVj-D%3Dv%2B53-hLKRx2C39KXuTDTo41pYgQ%40mail.gmail.com.
Have you checked the log? Is OpenPnP actually commanding it to go beyond the soft limits?
If not: The soft limit must be set for the worst case
motion. The Liteplacer is extremely shaky i.e. when you go at full
blast to the soft limit, the switch might be triggered by the
portal, head or belts swinging around.
On my Liteplacer I had to set soft limits several mm away from
the switches. You can test this using the and buttons back and forth rapidly and at full machine
speed.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0718d0e3-4db7-4790-9304-d059deaee9can%40googlegroups.com.
Hi fxframes,
Strange. During development I did exactly that a gazillion times and it never did that.
Some ideas:
Please send the log of that session. Note, OpenPnP keeps the last
100 logs around, so you should be able to find it.
See the $HOMEDIR/.openpnp2/log/
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/91fdbceb-c909-4358-8d43-9417486ea108n%40googlegroups.com.
Hi fxframes,
Be mindful of the selected tool in the Machine Controls.
Issues & Solutions will automatically select the right tool
for a task when you select a solution that needs positioning
that tool. This might be unexpected! So when it selects the
camera, for instance, and you then want to jog Z, nothing
(visibly) happens. You need to switch back to the nozzle if you
want the nozzle.
I'm aware of pros and cons of this behavior. Personally,
I found it useful, but I'm open for
discussion. I could also make it conditional on the Auto
tool select switch:
https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration:-Machine-Setup#the-machine-setup-tree
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f0ffa1a8-6c6e-48f1-8aea-e710124f861en%40googlegroups.com.
> One another note, wouldn't you expect a little interaction between the backlash setting and the XY calibration?
By "XY calibration" you mean Units per Pixel, right?
In the Camera calibration, that comes before the
backlash calibration, I tried to exclude any influence of
backlash, by forcing the machine to execute huge deliberate
"backlash compensation" moves. All locations are always approached
slowly, and going into the same direction +X/+Y.
If you look closely in the video, you see these slow diagonal
approaches it in the overlaid machine view:
https://youtu.be/md68n_J7uto?t=34
> And vice-versa, if the pix/in setting is a bit off,
wouldn't that influence the backlash results?
Yes, Units per Pixel must be set, before backlash
calibration. In fact, Issues & Solutions takes great care to
propose these steps in the right order. The order is one of the
most complex problems for (typically new) users to get right,
sometimes it would even involve iterative re-visits to
get good precision. I&S aims to remedy that.
Having said that, as long as Units per Pixel are not off by more
than say ±5% (which is a lot), it would not actually matter,
because the distances involved are tiny and backlash is usually
quite inconsistent anyway, at last for "mechanically challenged"
machines like mine.
But in general you are right that things interfere back and
forth, and there are some complex dependency tracking updating
mechanisms built-in, so that chicken-and-egg loops can be broken.
One example is the calibration of the precise nozzle-to-head
offsets. Changing the offsets it also (by implication) changes the
bottom camera position, because it was earlier calibrated using
the old imprecise nozzle-to-head offsets that was
taken from manually jogging the nozzle tip over the fiducial.
Therefore, after the precise nozzle-to-head offsets calibration,
OpenPnP will automatically update the bottom camera position by
the amount of the adjustment.
You can look into the log and filter by INFO level messages to
see the most important updates.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d3d3faed-744c-4ebe-b9a0-96b6061eb70en%40googlegroups.com.
It seems your preliminary nozzle head offsets that you set when you moved your nozzle to the primary fiducial, are not accurate in X, Y, perhaps even in Z. I'm speaking about this step in the video:
https://youtu.be/md68n_J7uto?t=109
I'm very interested in knowing if this is a bug. So please help me diagnose it, by answering some questions to exclude other reasons (this is in no way a "test" 😃, there is no doing it "right" or "wrong", I know the realities of DIY projects 🤣):
Now for fixing it:
First go to the nozzle and look at the offsets. Write them down. Is Z = 0?
You can re-do this step by switching on the Include Solved?
checkbox on the Issues & Solutions tab.
Then select the "Nozzle N1 offsets for the primary fiducial"
issue and press Reopen.
Then follow the instructions to re-do it.
Then compare the offsets with the ones
you've written down. Report back, please.
Check, if your bottom camera is still at the right spot, i.e. the nozzle tip centered in its view, if you press this button:
Report back.
If not, you might have to re-do the following Issues & Solutions steps too. Please report any recurring anomalies. 🤔
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f28eeaf5-c525-4ad7-a0eb-8229d0a7126bn%40googlegroups.com.
Thanks for that feedback. I'll have a look again.
I wish I had a multi-nozzle machine myself, for testing 😅
_Mark
--
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/dBg7txMB0R0/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/bd1766d7-3c09-4301-a581-822318ca387dn%40googlegroups.com.
Hi Zdenko
I'm looking at the code and I don't see any problems. But this stuff is complex, I'm not saying there are no bugs 🤯😵💫
So I would be extremely interested in the original log, when you
had the problem. Note, OpenPnP keeps a 100 old logs around, so I
guess you could find it. Look in the
$HOMEDIR/.openpnp2/log/ dir.
If you have grep or similar, search for " head offsets to "
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/237197ef-b9c2-e3ea-adb1-6b3d305aaf67%40makr.zone.
On 10 Sep 2021, at 19:47, ma...@makr.zone wrote:
It seems your preliminary nozzle head offsets that you set when you moved your nozzle to the primary fiducial, are not accurate in X, Y, perhaps even in Z. I'm speaking about this step in the video:
https://youtu.be/md68n_J7uto?t=109
I'm very interested in knowing if this is a bug. So please help me diagnose it, by answering some questions to exclude other reasons (this is in no way a "test" 😃, there is no doing it "right" or "wrong", I know the realities of DIY projects 🤣):
- Since you performed that calibration step (above): have you never changed the offsets by hand?
- moved or crashed the Zmax endswitch?
- changed the controller settings?
- moved the calibration rig?
Now for fixing it:
First go to the nozzle and look at the offsets. Write them down. Is Z = 0?
<comppiblipdepppk.png>
You can re-do this step by switching on the Include Solved? checkbox on the Issues & Solutions tab.
Then select the "Nozzle N1 offsets for the primary fiducial" issue and press Reopen.
<alehnjpkhocjihmb.png>
Then follow the instructions to re-do it.
Then compare the offsets with the ones you've written down. Report back, please.
Check, if your bottom camera is still at the right spot, i.e. the nozzle tip centered in its view, if you press this button:
<kjligjbhhcacmhlk.png>
> A question before reporting on the rest, it seems I have two different Z axes for the nozzle and the camera. Is this right? I can’t remember why this is so.
Yes, the camera has a virtual Z and Rotation axis. If it
had the same physical Z axis as the nozzle, it would move
when going to a location with Z coordinate, causing crashes. Do not set it to the same axis.
Use cases etc. explained here:
https://github.com/openpnp/openpnp/wiki/Machine-Axes#referencevirtualaxis
The virtual Z axis has become very important for this:
Thanks for the precise description, I finally found and fixed that bug!
Will make a fix/upgrade soon.
Workaround: Set the Offsets to zero before using that
solution. Sorry about that.
_Mark
--
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/dBg7txMB0R0/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/11CE5BDF-EC3F-4C90-9A35-0C2316ED8AA8%40gmail.com.
1. The Actuator Problem: You have probably used the Nozzle
solution, right?
This will assign a vacuum sensing actuator by default:
But that should be ok to leave like this, even if you don't have them (yet). So I will change it, to not report that issue when all nozzle tips have Measurement Method = None.
2. The tab problem: I believe this is a bug of the theming
(Appearance) that was recently brought in.
Like I said in the Github Issue, I have tried everything to fix
it. The problem is definitely not the code doing it:
https://github.com/openpnp/openpnp/issues/1199
I'll think about adding a switch in the machine.xml to disable
the status indicator.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d52a6ed3-ff58-4fc3-90b0-6aac8151bac8n%40googlegroups.com.
Ok, regarding the tabs: in the next testing version:
...
<home-after-enabled>true</home-after-enabled>
<solutions show-indicator="false"
target-milestone="Calibration">
<dismissed-solutions class="java.util.HashSet">
...
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d52a6ed3-ff58-4fc3-90b0-6aac8151bac8n%40googlegroups.com.
Thanks to all testers for the feedback! 👍👍👍
Hi everybody,Another one: Automatic Machine Calibration using Issues & Solutions - Round 6This one (finally) deploys 3D Units per Pixel Calibration to all vision operations! One piece of hard work 😅 😅 😅Including a brand-new Wiki page:Other stuff described here:This PR touches vision feeder classes AdvancedLoosePartFeeder, ReferenceDragFeeder, ReferenceLeverFeeder and quite possibly others that use vision that I don't personally use.These are untested, so I need your help.Sooner or later these changes will enter the regular OpenPnP version, so up-front testing is crucial for those that use these classes.Overview still here:
Hi fxframes,
thanks again, for the testing effort. Sorry about that!
Silly me, I used a simplified test case, where the homing
fiducial is the same as the primary calibration fiducial, hence I
did not notice. Stupid rookie test case mistake.
I'll fix it as soon as possible.
_Mark
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/53d3ebf7-6f69-4b3d-8314-fc0eae5a18ecn%40googlegroups.com.
Fixed!
Please upgrade. Again, sorry for that, and thanks for the patient testing 😅
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4d061fff-7152-ba32-ce6e-4d28bdb89f1c%40makr.zone.