Automatic Machine Calibration using Issues & Solutions

[ma...@makr.zone]

Hi all

I've uploaded a video of the Automatic Machine Calibration using Issues & Solutions that I'm working on:

https://youtu.be/md68n_J7uto

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

[Jonathan Oxer]

Hi Mark,

The setup assistance features that have been added to OpenPnP in recent times are amazing. Thanks for all your work on this: it's easy to get past the setup stage and then never think about it again, but you keep iterating and improving on it. The setup process is critical to having a machine that works well, so your work on this makes it *much* easier to get past the initial hurdles quickly without compromising the quality of the setup.

The calibration features in the video look great. I don't have any feedback or suggestions, other than to say that I can't wait to give it a try.

Cheers

Jon

--
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.

[Shai]

This looks amazing Mark! Is the idea to then use this to integrate auto focus camera or is that wishful thinking? ;)

[ma...@makr.zone]

> 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.

[ma...@makr.zone]

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.

[Shai]

My thinking was auto focus for different heights for the downward looking cam. For example if feeders are at different height than board, then the downward cam would be able to focus on both to align crosshairs for easier feeder/fiducial setup.

[ma...@makr.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.

[fxframes]

This looks fantastic, can’t wait! 

[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:

https://youtu.be/md68n_J7uto

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:

https://openpnp.org/test-downloads/

This will need some broad machine spectrum testing, who's helping?
😃

Thanks!

_Mark

[ma...@makr.zone]

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.

[james.edwa...@gmail.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:

https://youtu.be/md68n_J7uto

 

 

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:

https://openpnp.org/test-downloads/

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:

 

 

https://youtu.be/md68n_J7uto

 

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.

[ma...@makr.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.

[Zdenko Stanec]

Count me in Mark,

I will do the testing, 

I will start tomorrow and I will give you some feedback/vids. 🤠

Regards,

Zdenko,

[jdlv]

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

--

[jdlv]

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.

[tony...@att.net]

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.

[ma...@makr.zone]

Hi jdlv,

Thanks for testing! 😄

There are two issues:

1. The first was already pointed out by Tony. I guess your fiducial is too close to the soft limit, you need a ~120mm+ X, Y distance from soft limits, even better is a machine central location. I must improve that Wiki section:
   https://github.com/openpnp/openpnp/wiki/Vision-Solutions#calibration-primary-fiducial
2. The second is a dependency bug (thanks for reporting it): All these following steps (under the red dashed line) should not appear, before you set the fiducial Z is also set by moving the Nozzle to the two fiducials. These two steps correctly only appear when you press "Find Issues & Solutions" again, after having solved the first two, i.e. after having set the pair of fiducial X and Y. But the others (that now erroneously appear) should only pop up even later, after you have set the fiducials' Z as well, and after you pressed "Find Issues & Solutions" yet again. Each of these solutions builds on top of the others. You may have a look at the video and will understand why this information is needed.
   

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

Am 17.08.2021 um 20:55 schrieb tony...@att.net:

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

snip

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

snip

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c27d417d-e3cc-48f9-b455-e09f1a1a9bebn%40googlegroups.com.

[ma...@makr.zone]

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.

[jdlv]

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.

[ma...@makr.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.

[ozzy_sv]

it is not clear why the diagnostics thinks that I have no nozles ))

среда, 18 августа 2021 г. в 18:19:00 UTC+3, ma...@makr.zone:

[ozzy_sv]

config 

среда, 18 августа 2021 г. в 21:55:30 UTC+3, ozzy_sv:

[ozzy_sv]

_Mark 

  and is it possible to make it so that in the selected area the text can be copied for translation, not everyone knows English well

среда, 18 августа 2021 г. в 21:57:08 UTC+3, ozzy_sv:

[ma...@makr.zone]

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.

[jdlv]

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.

[ma...@makr.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.

[ozzy_sv]

I passed the test. even everything worked out.

среда, 18 августа 2021 г. в 23:39:17 UTC+3, ma...@makr.zone:

[ozzy_sv]

But for circles from a hole punch, you should increase the maximum value  (detect feature diameter on your video)  when setting the camera to a circle. I had value 180 and lacked literally 1 2 values in the big direction

среда, 18 августа 2021 г. в 23:54:09 UTC+3, ozzy_sv:

[ma...@makr.zone]

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.

[ma...@makr.zone]

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.

[ma...@makr.zone]

Hi all,

Thanks to valuable feedback from testers, I was able to create the second version:

https://github.com/openpnp/openpnp/pull/1253

Another testing version has been deployed. Please upgrade or download here:

https://openpnp.org/test-downloads/

_Mark

[jdlv]

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

As for the nozzle - camera offsets calibration results are very good!

joël

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/55846be4-0947-7125-0123-d98dcfe06c89%40makr.zone.

[ma...@makr.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.

[ma...@makr.zone]

Hi all,

Another round-up of enhancements and bug-fixes was deployed as a OpenPnP 2.0 testing-version. Testers please upgrade.

Description of changes here:

https://github.com/openpnp/openpnp/pull/1256

Overview with links here:

https://makr.zone/openpnp-automatic-machine-calibration-with-issues-solutions/676/

_Mark

On Sunday, August 15, 2021 at 12:01:33 AM UTC+2 ma...@makr.zone wrote:

[Zdenko Stanec]

Hello Mark,

I tested this new "Testing" release, I did not find any big issues and everything was clear and simple to me.

The only minor issue I found is after N3 and N4 (camera to nozzle offset), C3 and C4 stay on -30deg, where on N1 and N2 (C1, C2)  I think I didn't have that issue, I just pres P for park and all good.

I will keep testing it, it would be nice to have some "Machine calibration Reset" to simply start complete new "Machine calibration".

Best regards,

Zdenko

[ma...@makr.zone]

> 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.

[ma...@makr.zone]

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.

[Robert Harrison]

On my tinyg Liteplacer it I&S keeps asking me to change the MOVE_TO_COMMAND to use G1 but it moves like a snail if I do that and I have to set it back to G0 probably a tinyG thing !!!

[tony...@att.net]

I use G1 just fine.  You may need to up your OpenPnP jerk settings on each axis - I use 50000 on X and Y; 5000 on Z; and 240000 on A.

[Zdenko Stanec]

Hi Mark,

I tested the last "Test" revision, no issues so far,  Auto-Adjust is working well, but personally, I like the old looks. 😊😊

It seems to me that  Auto-Adjust is a bit slow for me because my settle time is a bit big.

Awesome work. 👍✌😁

Best regards,

Zdenko

[ma...@makr.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.

[tonyl...@gmail.com]

Hi Mark,

I've been going through the process (and doing a partial integration of my advanced camera calibration at the same time) and have a few observations:

1. It would be nice to have an "undo reopen button" for things that have already been solved - I accidentally clicked reopen on something I really didn't want to revisit but my only options at that point were to accept or dismiss.
2. The calibration fiducials don't have to be white on a black background - I used black on a white background and they worked just fine.  Both calibration fiducials don't have to be present on the machine at the same time.  I "stack" mine vertically to save space.  The operator just has to have the information to know which one to place on the machine at each step.
3. When I first tried the backlash calibration it would hit a soft limit exception because I had my calibration fiducials too close to the axis limits.  However, I don't have any place on my machine where I could meet the 250mm requirement described in the Wiki without moving a bunch of feeders.  While it's probably a good goal it doesn't seem absolutely necessary to get a decent calibration.  So I slightly modified your code in displacedAxisLocation (see highlighted section below) to limit at the soft limits rather than just blindly ignore them.  It seemed to work ok after that. 
4. The nozzle offset process is cool but one improvement to speed it up (not that it takes too long) would be to just lift the test object a couple of millimeters instead of all the way to safe Z before rotating and replacing it.
5. Initial bottom camera setup seems a bit incomplete - I expected its default Z to be set to the same coordinate as its head offset Z coordinate (set by auto-focus) but it wasn't.  Am I misunderstanding something?

    private Location displacedAxisLocation(HeadMountable movable, ReferenceControllerAxis axis,

            Location location, double displacement, boolean fullRange) throws Exception {

        location = movable.toHeadLocation(location);

        AxesLocation axesLocation = movable.toRaw(location);

        if (fullRange) {

            axesLocation = axesLocation.put(displacement < 0 ? 

                    new AxesLocation(axis, axis.getSoftLimitLow()) : 

                        new AxesLocation(axis, axis.getSoftLimitHigh()));

        }

        else {

            axesLocation = axesLocation.add(new AxesLocation(axis, displacement));

            if (axesLocation.getLengthCoordinate(axis).compareTo(axis.getSoftLimitLow()) < 0) {

                axesLocation = new AxesLocation(axis, axis.getSoftLimitLow());

            }

            if (axesLocation.getLengthCoordinate(axis).compareTo(axis.getSoftLimitHigh()) > 0) {

                axesLocation = new AxesLocation(axis, axis.getSoftLimitHigh());

            }

        }

        Location newLocation = movable.toTransformed(axesLocation);

        newLocation = movable.toHeadMountableLocation(newLocation);

        return newLocation;

    }

Regards,

Tony

[ma...@makr.zone]

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.

[ma...@makr.zone]

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.

[tonyl...@gmail.com]

Yeah, I don't really see any bottom camera use cases where we're trying to look at things at different distances from the camera so the 3D aspect is not really useful there.  I think it is still beneficial to run the calibration on it though to correct the tilt, rotation, and lens distortion.   One small problem is I need two different Z's for the bottom camera calibration (for top camera's I just use the already defined fiducials).  The first Z is easy enough - I just use the Z coordinate set by auto focus.  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?

[ma...@makr.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:

Z_a = Camera location Z (which is what the auto-focus calibrated)

Z_b1 = 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.

Z_b2 = 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.

Z_b3 = Safe Z minus 0.01mm (to make it outside the Safe Z zone)

And then:

Z_b = min(Z_b1, Z_b2, Z_b3)

But that's probably overkill.

Perhaps Z_b1 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.

[bert shivaan]

Would a use case be on pneumatic nozzle that only has 2 positions?

So tall parts are much lower than short parts?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/67d86bef-dcb9-b176-e206-ba7916ae94e7%40makr.zone.

[ma...@makr.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.

[Robert Harrison]

Hi Tony I'm still struggling to get G1 to work even though I have set up jerk rates.

Would you mind posting your tiny g setup and machine.xml and I'll try to resolve and report back.

[Robert Harrison]

Do I have to clear these from the I&S list as these are all set on each access and I would expect I&S to see this ?

r

[Robert Harrison]

My Tiny G settings

> $$

[fb]  firmware build            440.21

[fv]  firmware version            0.97

[hp]  hardware platform           1.00

[hv]  hardware version            8.00

[id]  TinyG ID                    9U6538-X4T

[ja]  junction acceleration  100000 mm

[ct]  chordal tolerance           0.0100 mm

[sl]  soft limit enable           0

[st]  switch type                 0 [0=NO,1=NC]

[mt]  motor idle timeout    4294967.00 Sec

[ej]  enable json mode            0 [0=text,1=JSON]

[jv]  json verbosity              2 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]

[js]  json serialize style        1 [0=relaxed,1=strict]

[tv]  text verbosity              1 [0=silent,1=verbose]

[qv]  queue report verbosity      0 [0=off,1=single,2=triple]

[sv]  status report verbosity     2 [0=off,1=filtered,2=verbose]

[si]  status interval           500 ms

[ec]  expand LF to CRLF on TX     0 [0=off,1=on]

[ee]  enable echo                 0 [0=off,1=on]

[ex]  enable flow control         1 [0=off,1=XON/XOFF, 2=RTS/CTS]

[baud] USB baud rate              5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]

[net] network mode                0 [0=master]

[gpl] default gcode plane         0 [0=G17,1=G18,2=G19]

[gun] default gcode units mode    1 [0=G20,1=G21]

[gco] default gcode coord system  1 [1-6 (G54-G59)]

[gpa] default gcode path control  2 [0=G61,1=G61.1,2=G64]

[gdi] default gcode distance mode 0 [0=G90,1=G91]

[1ma] m1 map to axis              0 [0=X,1=Y,2=Z...]

[1sa] m1 step angle               0.900 deg

[1tr] m1 travel per revolution   39.9990 mm

[1mi] m1 microsteps               8 [1,2,4,8]

[1po] m1 polarity                 0 [0=normal,1=reverse]

[1pm] m1 power management         1 [0=disabled,1=always on,2=in cycle,3=when moving]

[2ma] m2 map to axis              1 [0=X,1=Y,2=Z...]

[2sa] m2 step angle               0.900 deg

[2tr] m2 travel per revolution   39.9300 mm

[2mi] m2 microsteps               8 [1,2,4,8]

[2po] m2 polarity                 0 [0=normal,1=reverse]

[2pm] m2 power management         1 [0=disabled,1=always on,2=in cycle,3=when moving]

[3ma] m3 map to axis              2 [0=X,1=Y,2=Z...]

[3sa] m3 step angle               1.800 deg

[3tr] m3 travel per revolution    8.0000 mm

[3mi] m3 microsteps               8 [1,2,4,8]

[3po] m3 polarity                 1 [0=normal,1=reverse]

[3pm] m3 power management         1 [0=disabled,1=always on,2=in cycle,3=when moving]

[4ma] m4 map to axis              3 [0=X,1=Y,2=Z...]

[4sa] m4 step angle               0.900 deg

[4tr] m4 travel per revolution  160.0000 mm

[4mi] m4 microsteps               8 [1,2,4,8]

[4po] m4 polarity                 0 [0=normal,1=reverse]

[4pm] m4 power management         1 [0=disabled,1=always on,2=in cycle,3=when moving]

[xam] x axis mode                 1 [standard]

[xvm] x velocity maximum      10500 mm/min

[xfr] x feedrate maximum       8000 mm/min

[xtn] x travel minimum            0.000 mm

[xtm] x travel maximum          150.000 mm

[xjm] x jerk maximum           1200 mm/min^3 * 1 million

[xjh] x jerk homing             800 mm/min^3 * 1 million

[xjd] x junction deviation        0.0500 mm (larger is faster)

[xsn] x switch min                3 [0=off,1=homing,2=limit,3=limit+homing]

[xsx] x switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[xsv] x search velocity        2000 mm/min

[xlv] x latch velocity          100 mm/min

[xlb] x latch backoff             5.000 mm

[xzb] x zero backoff              1.000 mm

[yam] y axis mode                 1 [standard]

[yvm] y velocity maximum      10500 mm/min

[yfr] y feedrate maximum       8000 mm/min

[ytn] y travel minimum            0.000 mm

[ytm] y travel maximum          150.000 mm

[yjm] y jerk maximum            800 mm/min^3 * 1 million

[yjh] y jerk homing             800 mm/min^3 * 1 million

[yjd] y junction deviation        0.0500 mm (larger is faster)

[ysn] y switch min                3 [0=off,1=homing,2=limit,3=limit+homing]

[ysx] y switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[ysv] y search velocity        1800 mm/min

[ylv] y latch velocity          100 mm/min

[ylb] y latch backoff             5.000 mm

[yzb] y zero backoff              1.000 mm

[zam] z axis mode                 1 [standard]

[zvm] z velocity maximum       3000 mm/min

[zfr] z feedrate maximum       3000 mm/min

[ztn] z travel minimum            0.000 mm

[ztm] z travel maximum           75.000 mm

[zjm] z jerk maximum           2000 mm/min^3 * 1 million

[zjh] z jerk homing            2000 mm/min^3 * 1 million

[zjd] z junction deviation        0.0500 mm (larger is faster)

[zsn] z switch min                0 [0=off,1=homing,2=limit,3=limit+homing]

[zsx] z switch max                3 [0=off,1=homing,2=limit,3=limit+homing]

[zsv] z search velocity        1500 mm/min

[zlv] z latch velocity          100 mm/min

[zlb] z latch backoff             5.000 mm

[zzb] z zero backoff              2.000 mm

[aam] a axis mode                 1 [standard]

[avm] a velocity maximum      20000 deg/min

[afr] a feedrate maximum      20000 deg/min

[atn] a travel minimum           -1.000 deg

[atm] a travel maximum           -1.000 deg

[ajm] a jerk maximum            600 deg/min^3 * 1 million

[ajh] a jerk homing           11520 deg/min^3 * 1 million

[ajd] a junction deviation        0.0500 deg (larger is faster)

[ara] a radius value              0.1989 deg

[asn] a switch min                1 [0=off,1=homing,2=limit,3=limit+homing]

[asx] a switch max                0 [0=off,1=homing,2=limit,3=limit+homing]

[asv] a search velocity         600 deg/min

[alv] a latch velocity          100 deg/min

[alb] a latch backoff             5.000 deg

[azb] a zero backoff              2.000 deg

[bam] b axis mode                 0 [disabled]

[bvm] b velocity maximum       3600 deg/min

[bfr] b feedrate maximum       3600 deg/min

[btn] b travel minimum           -1.000 deg

[btm] b travel maximum           -1.000 deg

[bjm] b jerk maximum             20 deg/min^3 * 1 million

[bjd] b junction deviation        0.0500 deg (larger is faster)

[bra] b radius value              1.0000 deg

[cam] c axis mode                 0 [disabled]

[cvm] c velocity maximum       3600 deg/min

[cfr] c feedrate maximum       3600 deg/min

[ctn] c travel minimum           -1.000 deg

[ctm] c travel maximum           -1.000 deg

[cjm] c jerk maximum             20 deg/min^3 * 1 million

[cjd] c junction deviation        0.0500 deg (larger is faster)

[cra] c radius value              1.0000 deg

[p1frq] pwm frequency               100 Hz

[p1csl] pwm cw speed lo            1000 RPM

[p1csh] pwm cw speed hi            2000 RPM

[p1cpl] pwm cw phase lo           0.125 [0..1]

[p1cph] pwm cw phase hi           0.200 [0..1]

[p1wsl] pwm ccw speed lo           1000 RPM

[p1wsh] pwm ccw speed hi           2000 RPM

[p1wpl] pwm ccw phase lo          0.125 [0..1]

[p1wph] pwm ccw phase hi          0.200 [0..1]

[p1pof] pwm phase off             0.100 [0..1]

[g54x] g54 x offset               0.000 mm

[g54y] g54 y offset               0.000 mm

[g54z] g54 z offset               0.000 mm

[g54a] g54 a offset               0.000 deg

[g54b] g54 b offset               0.000 deg

[g54c] g54 c offset               0.000 deg

[g55x] g55 x offset              75.000 mm

[g55y] g55 y offset              75.000 mm

[g55z] g55 z offset               0.000 mm

[g55a] g55 a offset               0.000 deg

[g55b] g55 b offset               0.000 deg

[g55c] g55 c offset               0.000 deg

[g56x] g56 x offset               0.000 mm

[g56y] g56 y offset               0.000 mm

[g56z] g56 z offset               0.000 mm

[g56a] g56 a offset               0.000 deg

[g56b] g56 b offset               0.000 deg

[g56c] g56 c offset               0.000 deg

[g57x] g57 x offset               0.000 mm

[g57y] g57 y offset               0.000 mm

[g57z] g57 z offset               0.000 mm

[g57a] g57 a offset               0.000 deg

[g57b] g57 b offset               0.000 deg

[g57c] g57 c offset               0.000 deg

[g58x] g58 x offset               0.000 mm

[g58y] g58 y offset               0.000 mm

[g58z] g58 z offset               0.000 mm

[g58a] g58 a offset               0.000 deg

[g58b] g58 b offset               0.000 deg

[g58c] g58 c offset               0.000 deg

[g59x] g59 x offset               0.000 mm

[g59y] g59 y offset               0.000 mm

[g59z] g59 z offset               0.000 mm

[g59a] g59 a offset               0.000 deg

[g59b] g59 b offset               0.000 deg

[g59c] g59 c offset               0.000 deg

[g92x] g92 x offset               0.000 mm

[g92y] g92 y offset               0.000 mm

[g92z] g92 z offset               0.000 mm

[g92a] g92 a offset               0.000 deg

[g92b] g92 b offset               0.000 deg

[g92c] g92 c offset               0.000 deg

[g28x] g28 x position             0.000 mm

[g28y] g28 y position             0.000 mm

[g28z] g28 z position             0.000 mm

[g28a] g28 a position             0.000 deg

[g28b] g28 b position             0.000 deg

[g28c] g28 c position             0.000 deg

[g30x] g30 x position             0.000 mm

[g30y] g30 y position             0.000 mm

[g30z] g30 z position             0.000 mm

[g30a] g30 a position             0.000 deg

[g30b] g30 b position             0.000 deg

[g30c] g30 c position             0.000 deg

tinyg [mm] ok>

[ma...@makr.zone]

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.

[Robert Harrison]

Thamks mark I'll search now. I set the jerk on all the axis this morning x,y,z,c and the message is still coming up let me try again.

r

[ma...@makr.zone]

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.

[ma...@makr.zone]

Hi everybody,

Another one: Automatic Machine Calibration using Issues & Solutions - Round 6

This one (finally) deploys 3D Units per Pixel Calibration to all vision operations! One piece of hard work 😅 😅 😅

Including a brand-new Wiki page: 

https://github.com/openpnp/openpnp/wiki/3D-Units-per-Pixel

Other stuff described here:

https://github.com/openpnp/openpnp/pull/1263

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:

[tonyl...@gmail.com]

Here are my latest TinyG settings:

> $$

[fb]  firmware build            440.21

[fv]  firmware version            0.97

[hp]  hardware platform           1.00

[hv]  hardware version            8.00

[id]  TinyG ID                    7X2109-JGS

[ja]  junction acceleration  500000 mm

[ct]  chordal tolerance           0.0100 mm

[sl]  soft limit enable           0

[st]  switch type                 0 [0=NO,1=NC]

[mt]  motor idle timeout    1000000.00 Sec

[ej]  enable json mode            0 [0=text,1=JSON]

[jv]  json verbosity              0 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]

[js]  json serialize style        0 [0=relaxed,1=strict]

[tv]  text verbosity              1 [0=silent,1=verbose]

[qv]  queue report verbosity      0 [0=off,1=single,2=triple]

[sv]  status report verbosity     0 [0=off,1=filtered,2=verbose]

[si]  status interval    4000000000 ms

[ec]  expand LF to CRLF on TX     0 [0=off,1=on]

[ee]  enable echo                 0 [0=off,1=on]

[ex]  enable flow control         2 [0=off,1=XON/XOFF, 2=RTS/CTS]

[baud] USB baud rate              5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]

[net] network mode                0 [0=master]

[gpl] default gcode plane         0 [0=G17,1=G18,2=G19]

[gun] default gcode units mode    1 [0=G20,1=G21]

[gco] default gcode coord system  1 [1-6 (G54-G59)]

[gpa] default gcode path control  0 [0=G61,1=G61.1,2=G64]

[gdi] default gcode distance mode 0 [0=G90,1=G91]

[1ma] m1 map to axis              0 [0=X,1=Y,2=Z...]

[1sa] m1 step angle               0.900 deg

[1tr] m1 travel per revolution   39.9286 mm

[1mi] m1 microsteps               8 [1,2,4,8]

[1po] m1 polarity                 0 [0=normal,1=reverse]

[1pm] m1 power management         2 [0=disabled,1=always on,2=in cycle,3=when moving]

[2ma] m2 map to axis              1 [0=X,1=Y,2=Z...]

[2sa] m2 step angle               0.900 deg

[2tr] m2 travel per revolution   39.9514 mm

[2mi] m2 microsteps               8 [1,2,4,8]

[2po] m2 polarity                 0 [0=normal,1=reverse]

[2pm] m2 power management         2 [0=disabled,1=always on,2=in cycle,3=when moving]

[3ma] m3 map to axis              2 [0=X,1=Y,2=Z...]

[3sa] m3 step angle               1.800 deg

[3tr] m3 travel per revolution    8.0000 mm

[3mi] m3 microsteps               8 [1,2,4,8]

[3po] m3 polarity                 1 [0=normal,1=reverse]

[3pm] m3 power management         2 [0=disabled,1=always on,2=in cycle,3=when moving]

[4ma] m4 map to axis              3 [0=X,1=Y,2=Z...]

[4sa] m4 step angle               0.900 deg

[4tr] m4 travel per revolution  160.0000 mm

[4mi] m4 microsteps               8 [1,2,4,8]

[4po] m4 polarity                 0 [0=normal,1=reverse]

[4pm] m4 power management         2 [0=disabled,1=always on,2=in cycle,3=when moving]

[xam] x axis mode                 1 [standard]

[xvm] x velocity maximum      10000 mm/min

[xfr] x feedrate maximum      10000 mm/min

[xtn] x travel minimum            0.000 mm

[xtm] x travel maximum          600.000 mm

[xjm] x jerk maximum           1000 mm/min^3 * 1 million

[xjh] x jerk homing            2000 mm/min^3 * 1 million

[xjd] x junction deviation        0.0100 mm (larger is faster)

[xsn] x switch min                3 [0=off,1=homing,2=limit,3=limit+homing]

[xsx] x switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[xsv] x search velocity        2000 mm/min

[xlv] x latch velocity         1000 mm/min

[xlb] x latch backoff            16.000 mm

[xzb] x zero backoff              2.000 mm

[yam] y axis mode                 1 [standard]

[yvm] y velocity maximum      10000 mm/min

[yfr] y feedrate maximum      10000 mm/min

[ytn] y travel minimum            0.000 mm

[ytm] y travel maximum          400.000 mm

[yjm] y jerk maximum           1000 mm/min^3 * 1 million

[yjh] y jerk homing            2000 mm/min^3 * 1 million

[yjd] y junction deviation        0.0100 mm (larger is faster)

[ysn] y switch min                3 [0=off,1=homing,2=limit,3=limit+homing]

[ysx] y switch max                2 [0=off,1=homing,2=limit,3=limit+homing]

[ysv] y search velocity        2000 mm/min

[ylv] y latch velocity         1000 mm/min

[ylb] y latch backoff            13.000 mm

[yzb] y zero backoff              2.000 mm

[zam] z axis mode                 1 [standard]

[zvm] z velocity maximum       5000 mm/min

[zfr] z feedrate maximum       2000 mm/min

[ztn] z travel minimum            0.000 mm

[ztm] z travel maximum           80.000 mm

[zjm] z jerk maximum            500 mm/min^3 * 1 million

[zjh] z jerk homing             500 mm/min^3 * 1 million

[zjd] z junction deviation        0.0100 mm (larger is faster)

[zsn] z switch min                0 [0=off,1=homing,2=limit,3=limit+homing]

[zsx] z switch max                3 [0=off,1=homing,2=limit,3=limit+homing]

[zsv] z search velocity        1000 mm/min

[zlv] z latch velocity          100 mm/min

[zlb] z latch backoff             4.000 mm

[zzb] z zero backoff              2.000 mm

[aam] a axis mode                 1 [standard]

[avm] a velocity maximum      50000 deg/min

[afr] a feedrate maximum     200000 deg/min

[atn] a travel minimum           -1.000 deg

[atm] a travel maximum          600.000 deg

[ajm] a jerk maximum           5000 deg/min^3 * 1 million

[ajh] a jerk homing            5000 deg/min^3 * 1 million

[ajd] a junction deviation        0.0100 deg (larger is faster)

[ara] a radius value              0.1990 deg

[asn] a switch min                0 [0=off,1=homing,2=limit,3=limit+homing]

[fxframes]

Awesome Mark, thank you!

I’m back and will do some testing next week.

[Robert Harrison]

Tony et al...

So the battle continues... 

Looking at my log (now that I understand G Code a little more)

G0 Y200 F1000 basically ignores the feed rate of 1,000 mm/min and moves at machine maximum 10,000 mm/min Tested by entering on command line

G1 Y200 F1000 basically uses the feed rate of 1,000 mm/min ands is 10 times slower. Tested by entering on command line

Now I have changed the feed rate in the Y axis config from 16 mm/sec to 160 mm/s and clicked apply but this has not changed the F1000 command to be fair it is actually F990 see log below

Can anyone shine any light on how to change the F value in the G1 & G0 commands. Even though G0 ignores it.

Kind regards 

Robert

--- DUMP OF LOG FOR MOVE G1

2021-08-30 09:34:12.042 GcodeDriver DEBUG: [serial://COM3] >> G1   Y64.0000  F990.00 ; move to target, 5000

2021-08-30 09:34:12.057 GcodeDriver$ReaderThread TRACE: [serial://COM3] << tinyg [mm] ok>

2021-08-30 09:34:12.057 GcodeDriver TRACE: [serial://COM3] confirmed G1   Y64.0000  F990.00 ; move to target

2021-08-30 09:34:12.059 GcodeDriver DEBUG: [serial://COM3] >> M201.3, 5000

2021-08-30 09:34:12.073 GcodeDriver$ReaderThread TRACE: [serial://COM3] << tinyg [mm] ok>

2021-08-30 09:34:12.074 GcodeDriver TRACE: [serial://COM3] confirmed M201.3

2021-08-30 09:34:12.074 GcodeDriver DEBUG: [serial://COM3] >> G1   Y64.4000  F100.00 ; move to target, 5000

[ma...@makr.zone]

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.

[Robert Harrison]

Hi Mark,

This is what my I&S screen shows. I cant clear the axis issues either despite having set all three values on each axis.

Hope this is helpful.

r

[Robert Harrison]

Fixed it my Max Feed Rate was set to 1000 here and I've now set it to 10,000 and all is good.

[Robert Harrison]

Should I be using the GcodeAsyncDriver ?

[ma...@makr.zone]

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.

[Saito Ryosuke]

Hi, Mark. Thanks again.
I am trying your test release which was delivered on the 5th.
Version : 2021-09-05_18-21-56.6f36853

From the milestone, I tried to calibrate the X axis.
To start the calibration, I did the following steps to prepare.
1. set up the test fiducial (FiducialHome.pdf) at the focus height
2. Jogged the downward-facing camera on the head to the center of the fiducial at 1.
3. select "Calibrate backlash compensation for axis X." in the "Issues & Solutions" tab.
4. click "Accept

The X axis of the head moves 1.347, the Y axis moves 0.169, and the error message "Subject not found.

Here is a video of this scene.
https://www.youtube.com/watch?v=ybGVW8KmTTI

It seems that sometimes the same procedure can start the calibration correctly.
Immediately after proceeding to "Random Move Accuracy Test Step 1"
An error message "Subject not found." pops up and the calibration stops.

Here is a video of this scene.
https://youtu.be/JydbBlKm1eo?t=418

The OpenPnP log taken at the same time as this video was taken is shared below.
http://gofile.me/3PODq/5gxPS4Dek

I want to solve this issue. I would like some tips on what I need to check first.
Thanks.

Ryosuke

2021年8月25日(水) 3:43 ma...@makr.zone <ma...@makr.zone>:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9a89eca6-62c1-a870-7b22-44430ddfa04e%40makr.zone.

[ma...@makr.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.

[Saito Ryosuke]

Hi, Mark. Thanks for the advice.
I was able to successfully calibrate the X axis while checking the camera settings.



## Downward facing camera settings
The downward facing camera was set to "FixedTime" "267mSec".
I chose "Euclidean" from the Settle Method and successfully completed the X-axis calibration.
It is difficult to judge whether this setting is appropriate or not because I don't know enough about each parameter, but anyway, the X axis has been solved.

## Calibrating the X-axis
The calibration of the X-axis was successful and I saw the graph.
I noticed that the "Absolute" value of "Error at step" was accumulating errors in a linear pattern.
I understand that the error shown in this graph is corrected by calibration.  Is this understanding correct?
Because, at the moment, I cannot find any way to correct the value of Absolute.

(Do I need to correct the Smoothie parameters?).

//------------
## Calibrating the Y axis
In the process of calibrating the Y axis, I ran into a problem that I don't know the way out of.
"Accuracy Test Step 85-100", when the fiducial moves in the negative direction of the Y-axis.
In "Accuracy Test Step 85-100", when the fiducial was moving in the negative direction on the Y-axis, the green line surrounding the fiducial mark was decreasing as it moved away from the starting point.
The green line around the fiducial mark decreases as it moves away from the starting point, and I am unable to solve the problem of the calibration failing at around 100.

I suspect the settings in "Machine Setup" - "Vision" - "Fiducial Locator".
I tried loosening the range of "Mask Circle" (from 300 to 500), which I had defined additionally,

But I could not solve the problem of the green line around the fiducial being cut out.



If there are any other points I should check, I'd love to hear from you.

The current machine.xml and the log file when the Y axis failed to calibrate
http://gofile.me/3PODq/v8KWd4QRv


By the way, I still haven't solved the problem of the axis "running away" at the start of calibration. Do you have any experience with this situation?
The fiducial mark was definitely in the center of the crosshairs when I started the calibration....

I am convinced that this is not a hardware problem (noise, etc.). This is because the position and direction are repeatable. ;-)

I've been going back and forth between the SMT machine and the PC to start calibration, and I'm starting to get some exercise. haha


Thanks.
Ryosuke

2021年9月7日(火) 17:45 ma...@makr.zone <ma...@makr.zone>:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e2ecbfb-3640-af41-9fce-8124ebec27a1%40makr.zone.

[ma...@makr.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?

_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/CAH6K8ZWtZzfYLy%2Bdg1hxSuEq8ThGi03Nx9uaEoXOtb_35%2B3Y4Q%40mail.gmail.com.

[Saito Ryosuke]

Hi mark,
Thank you for your support!

## Understanding of camera parameters.

>I guess you've already looked at the WIki?

>https://github.com/openpnp/openpnp/wiki/Camera-Settling#advanced-settle-methods-and-diagnostics

Yes, I often come back to this document and read it over.

It seems that the units of the parameter you specify for "Center Mask" are not clear.
I give a value such as "1.000" as the setting value, but am I correct in understanding that this is "mm (1/1000meter)"?
Is this a function equivalent to "MaskCircle" - "diameter" in the pipeline?

## Another topic about cameras
Changing the camera settings will (of course) invalidate the calibration values.
I didn't notice for a while that the calibrated axes were invalidated.
It should be made clear to the user on the screen where the camera parameters are modified that changing the parameters will invalidate the calibration that has been performed up to that point.
I think it needs to be communicated to the user that changing the camera parameters will invalidate the previously performed calibration.

## not good value of "random" in calibration result.

>Can you please send a log?

Of course. I've tried to calibrate X-Axis several times.
I'll share two of the logs.
01 is a case where the log shows that there was an error and it appears to have been aborted.
02 is a case where the calibration appears to have completed successfully.
However, the random value is still not good.

In this thread I will probably continue to share the logs.
Instead of individual files, I will share a dedicated directory.
http://gofile.me/3PODq/2qILJRrOi
I've also saved the videos as files. Please give me a shout if a Youtube link would be more convenient.

Thanks.
Ryosuke

2021年9月8日(水) 2:18 ma...@makr.zone <ma...@makr.zone>:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/07eeee6a-337c-e8fa-2dc3-d37830d9fb63%40makr.zone.

[ma...@makr.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

> Changing the camera settings will (of course) invalidate the calibration values.

What settings exactly do you mean? It cannot be generalized.

> I didn't notice for a while that the calibrated axes were invalidated.

If you refer to Backlash Calibration on the axes, then no, it should not be invalidated.

If you refer to Units per Pixel, then it has nothing to do with the axes, but yes, Units per Pixel might be invalidated if you change some camera settings like the mode/resolution of the camera. But not all resolution changes invalidate them, for instance, on my ELP FullHD camera I can switch between FullHD and HD and the Units per Pixel are still valid, because the camera does crop the view instead of scaling it. So automatic invalidation is difficult for OpenPnP to detect. If we start going down that road, it is endless: OpenPnP will also not detect if you mount your camera higher up, or if you exchange the lens. This is machine engineering, some responsibility will always remain with you 😎

I'll have a look at the logs.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAH6K8ZU10BFT0Vhd3Vj6H66kW3LUPEmk2x9dNDZE8frhO6U1QA%40mail.gmail.com.

[Saito Ryosuke]

Hi mark,

The behavior of the "Center Mask" was completely unexpected.
Now I feel like I've conquered the settings of this screen ;-)

>What settings exactly do you mean?

This was caused by my simple imagination that if the camera settings were changed, it would affect the calibration results. I thought.
But sure enough. If there are no factors such as the focal length of the camera or the distance between the object and the camera, which change the length corresponding to one pixel distance, the calibration is valid.
I understand that if gain or contrast changes, it is still valid, and the same is true for shutter speed, etc.

What made me think this way was that the (finally) successful calibration of the X axis (the graph) was lost for some reason, and the "no data" message appeared.
The reason why I thought this way is because I experienced an incident where the (finally) successful calibration of the X axis (the graph) somehow disappeared and became "no data". (Reference Machine - Axes - ReferenceControllerAxis X screen)
I still can't figure out what causes the "no data" message. Oh, it's gone again...

I always believe that I am responsible for undesirable results. I must be doing something wrong.
After a successful calibration, the last operation I performed was to change the "Settle Threshold" in TopCamera.
This led me to believe that the calibration would be invalidated if the camera settings were changed.
However, it turns out that this understanding is not always correct.

//----

I found out the procedure to lose the calibration result of the X axis.
Maybe this test version still doesn't save the calibration results?
Then I can focus on the results of the calibration.

1. run "Calibrate now" on the Reference Machine - Axes - ReferenceControllerAxis X screen.
2. wait until the calibration is complete.
3. view the calibration result graph
4. Click on the power icon of OpenPnP to shut down.
5. Close the OpenPnP application.
6. start the OpenPnP application.
7. click the power icon of OpenPnP again.
8. Perform the homing operation with the "Home" icon.
9. Check the calibration results on the Reference Machine - Axes - ReferenceControllerAxis X screen.
10. "no data" is displayed.

thanks
Ryosuke

2021年9月8日(水) 15:32 ma...@makr.zone <ma...@makr.zone>:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ab07209d-86fc-c732-0ae7-2d7611270290%40makr.zone.

[ma...@makr.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.

[fxframes]

Hello Mark,

Once again thank you for this.

Calibrating Z went fine, as well as the x axis backlash.

When calibrating the y backlash though, OpenPnP tried to move the head beyond y min, triggering a reset on the TinyG.

Thanks,

[fxframes]

Just adding that soft limits are enabled for y and also the y min switch is being normally used during homing.

[fxframes]

Some more info, it happens right after Accuracy Test 100, I just tried it again.

The head is already decelerating when it triggers the limit switch, so it must have missed just a little extra space.

The wiki for the z height calibration mentions 250 mm of space to each side, not sure if that's a fixed length in the algorithm, but that's not achievable in my machine, which has 490 mm of useful space between limit switches, ignoring the soft limits.

The primary fiducial is pretty much centered in the y axis, with about 22-23 cm to each side.

Thanks,

[ma...@makr.zone]

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.

[fxframes]

Thanks Mark, the head was probably approaching the soft limit too fast for what the frame is capable as you said.

I moved the lower soft limit a bit inside and that fixed it.

Thanks again.

[fxframes]

Hi Mark,

After the primary and secondary X,Y calibration, and after the primary Z setting, I went to "Calibration Rig" to move the head over the secondary fiducial to set Z there, but even though I had 0 as shown below, the head first moved in X,Y, crashed into my little support and only then brought Z up to 0.

[ma...@makr.zone]

Hi fxframes,

Strange. During development I did exactly that a gazillion times and it never did that.

Some ideas:

1. Please check the Safe Zone on your Z axis, i.e. make sure you did the Safe Z solutions right.
   
2. Check if there is a Z head offset on the nozzle. That would probably point to a bug.
   

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.

[fxframes]

Hi Mark,

It has probably something to do with the TinyG.

I restarted the machine and OpenPnP, was able to jog around normally.

Then I redid the Safe Z height and the Z axis became unresponsive.

The same thing has happened before when going through some of the procedures in this PR.

For whatever reason, when you commit any changes the TinyG gets confused, I seems.

And the only way to get the Z jog controls to work again is to power the TinyG off and on, not even a reset will do.

Thanks,

[ma...@makr.zone]

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.

[fxframes]

Hi Mark, thanks, that was it.

Now that I'm more aware of it, I kind of like it.

Maybe the text or background color or something in that box could call a bit more attention to it, just a suggestion.

One another note, wouldn't you expect a little interaction between the backlash setting and the XY calibration?

I mean, if you start with the XY calibration and "whatever" backlash settings the machine originally had, wouldn't re-running the same calibration after the backlash has been set change the parameters a bit? And vice-versa, if the pix/in setting is a bit off, wouldn't that influence the backlash results? Just curious.

Thanks,

[ma...@makr.zone]

> 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.

[fxframes]

Thanks Mark.

When doing the "calibrate precise camera «» N1 nozzle offsets" procedure, I'm running again into an error.

This soft limit can't be extended, the nozzle is already pushing against the PCB which is at -37.200 mm.

Any tips?

Thanks,

[fxframes]

Also, when the procedure starts the camera finds everything alright, diameter is good, the green circle is at the correct position and size, but the when the head is moved to the camera position, it lowers the nozzle at a slightly different position, outside of the confetti diameter, thus picking nothing up.

[ma...@makr.zone]

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 🤣):

1. Since you performed that calibration step (above): have you never changed the offsets by hand?
   
2. moved or crashed the Zmax endswitch?
3. changed the controller settings?
4. moved the calibration rig?
   

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.

[Zdenko Stanec]

I didn't do much for the last few days so I downloaded the latest test version today and calibrated 4 nozzle (two controller) machine without any issues so far.

I wanted to check this Backlash Compensation that is hitting soft limits now, works good for me, and after calibration, it seems the machine should be accurate enough. 😊😊

Br,

Zdenko

[Zdenko Stanec]

Regarding the last mp5 issue,

I had the same/similar issue, it seems for me if I already had some Nozzle Offsets on N1 N2 N3 and N4 when starting OpenPnP it would later reset to 0 when clicked on "Accept" in Nozzle Offset calibration and later Non of the nozzles would move in direction of "Connfetti" for pickup.

So what I did was, after starting OpenPNP, I deleted N1,N2,N3 and N4 offsets, and the went to calibrate the machine, after each Nozzle Offset I pressed "Accept" and then I pressed "Find issues and Solutions" to remove "Solved" Nozzle, then I proceeded to next nozzle, after all Nozzle Offsets were done I went to check if Offest were saved, they were..and I proceeded with next steps.

I didn't test it again to see if this is a bug or just imagination, but it solved my problem and Nozzles were picking "Confetti" after I did this... 😁😁

Regards,

Zdenko

[ma...@makr.zone]

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.

[ma...@makr.zone]

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 should find something like this:

MINGW64 ~/.openpnp2/log
$ grep "head offsets to" *
OpenPnP.86.log:2021-08-27 19:41:13.061 VisionSolutions INFO: Do not set nozzle N1 head offsets to (-78.651874, -22.788375, 0.000000, 0.000000 mm) as these are close to existing offsets (-78.667792, -23.036375, 0.000000, 0.000000 mm) and existing offsets might already have been be calibrated.
OpenPnP.86.log:2021-08-27 19:42:57.236 VisionSolutions INFO: Set nozzle N1 head offsets to (-79.667987, -23.035969, 0.000000, 0.000000 mm) (previously (-78.667792, -23.036375, 0.000000, 0.000000 mm))
OpenPnP.86.log:2021-08-27 19:42:57.236 ReferenceNozzle INFO: Set camera Up looking head offsets to (297.324473, 152.579977, -46.677500, 180.000000 mm) (previously (298.324668, 152.579571, -46.677500, 180.000000 mm))
OpenPnP.86.log:2021-08-27 19:48:04.343 ReferenceNozzle INFO: Set camera Up looking head offsets to (297.189211, 152.670605, -46.278000, 180.000000 mm) (previously (297.189211, 152.670605, -46.278000, 180.000000 mm))
OpenPnP.86.log:2021-08-27 19:49:15.956 CalibrationSolutions INFO: Set nozzle N1 head offsets to (-78.760991, -23.206832, 0.000000, 0.000000 mm) (previously (-79.667987, -23.035969, 0.000000, 0.000000 mm))
OpenPnP.86.log:2021-08-27 19:49:15.956 ReferenceNozzle INFO: Set camera Up looking head offsets to (298.096206, 152.499741, -46.278000, 180.000000 mm) (previously (297.189211, 152.670605, -46.278000, 180.000000 mm))
OpenPnP.87.log:2021-08-27 19:15:04.807 ReferenceNozzle INFO: Set camera Up looking head offsets to (298.224473, 152.679977, -46.677500, 180.000000 mm) (previously (298.224473, 152.679977, -46.677500, 180.000000 mm))
OpenPnP.87.log:2021-08-27 19:22:50.299 VisionSolutions INFO: Set nozzle N1 head offsets to (-78.767987, -22.935969, 0.000000, 0.000000 mm) (previously (-78.667792, -23.036375, 0.000000, 0.000000 mm))
OpenPnP.87.log:2021-08-27 19:30:20.212 ReferenceNozzle INFO: Set camera Up looking head offsets to (298.324668, 152.579571, -46.677500, 180.000000 mm) (previously (298.224473, 152.679977, -46.677500, 180.000000 mm))
OpenPnP.89.log:2021-08-27 17:54:10.656 ReferenceNozzle INFO: Set camera Up looking head offsets to (376.953127, 175.527047, -46.162500, 0.000000 mm) (previously (298.256154, 152.256221, -46.162500, 0.000000 mm))
OpenPnP.89.log:2021-08-27 17:54:10.657 VisionSolutions INFO: Set nozzle N1 head offsets to (-78.667792, -23.036375, 0.000000, 0.000000 mm) (previously (-78.696973, -23.270826, 0.000000, 0.000000 mm))
OpenPnP.90.log:2021-08-27 17:42:38.037 ReferenceNozzle INFO: Set camera Up looking head offsets to (298.256154, 152.256221, -46.162500, 0.000000 mm) (previously (298.256154, 152.256221, -46.162500, 0.000000 mm))
OpenPnP.90.log:2021-08-27 17:42:48.692 ReferenceNozzle INFO: Set camera Up looking head offsets to (298.256154, 152.256221, -46.162500, 0.000000 mm) (previously (298.256154, 152.256221, -46.162500, 0.000000 mm))

Then select the right log and send it, please 😁

Thanks! 💯

_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/237197ef-b9c2-e3ea-adb1-6b3d305aaf67%40makr.zone.

[fxframes]

Hello Mark,

Thanks for the reply. Ask away, no worries, I’ll be happy to help!

Re your questions:

• Since you performed that calibration step (above): have you never changed the offsets by hand? 

When going through the procedures of this PR there was a moment where I did change a Z value manually because the head crashed into the little support I made for the secondary fiducial. I mentioned this on my Sep 9, 2:02 post to this thread.

• moved or crashed the Zmax endswitch?
• changed the controller settings?
• moved the calibration rig?

The answer is no to all of the above.

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.

Considering the above is the current setup, the “original” offsets are below and yes Z=0.

And after I re-ran the Z calibration everything went to 0:

Thanks,

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 🤣):

1. Since you performed that calibration step (above): have you never changed the offsets by hand?
   
2. moved or crashed the Zmax endswitch?
3. changed the controller settings?
4. 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>

[fxframes]

Hi Mark,

Just a quick note to a parallel issue, with the test version I started getting the following warnings again, even though I do not have a vacuum sensor installed.

This was happening before with an earlier PR - I can't remember which one right now but I'll find out and was already fixed in the main version.

Also - don't shoot the messenger :) - on the test version, right off the bat, as soon as OpenPnP is opened, this comes up. In the main version it doesn't happen until you click on I&S. Just letting you know, I know you already looked into it. Don't worry about it.

[ma...@makr.zone]

> 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:

https://github.com/openpnp/openpnp/wiki/3D-Units-per-Pixel

> And after I re-ran the Z calibration everything went to 0:

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.

[ma...@makr.zone]

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.

_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.

[ma...@makr.zone]

Ok, regarding the tabs: in the next testing version:

1. Start and Exit OpenPnP (so the new machine.xml version is written).
   
2. Open your machine.xml
3. Search for show-indicator
4. Set to "false"
   
5. Save
6. Restart OpenPnP
   

    ...

    <home-after-enabled>true</home-after-enabled>
      <solutions show-indicator="false" target-milestone="Calibration">
         <dismissed-solutions class="java.util.HashSet">

    ...

_Mark

Am 13.09.2021 um 16:32 schrieb fxframes:

--
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.

[ma...@makr.zone]

Hi all,

there is a new Automatic Machine Calibration testing version available.

This time it's only a rather small update:

https://github.com/openpnp/openpnp/pull/1291

Overview:

https://makr.zone/openpnp-automatic-machine-calibration-with-issues-solutions/676/

Thanks to all testers for the feedback! 👍👍👍

_Mark

On Saturday, August 28, 2021 at 5:36:21 PM UTC+2 ma...@makr.zone wrote:

Hi everybody,

Another one: Automatic Machine Calibration using Issues & Solutions - Round 6

This one (finally) deploys 3D Units per Pixel Calibration to all vision operations! One piece of hard work 😅 😅 😅

Including a brand-new Wiki page: 

https://github.com/openpnp/openpnp/wiki/3D-Units-per-Pixel

Other stuff described here:

https://github.com/openpnp/openpnp/pull/1263

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:

[fxframes]

Hi Mark,

I started over with all the procedures in this PR. All went well until the x backlash calibration.

I went almost all the way through, but after doing the "Speed 1X" test it went to the home fiducial and threw an error.

[ma...@makr.zone]

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.

[ma...@makr.zone]

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.

[fxframes]

Hi Mark,

No worries, thank you for making this available!

Now all steps worked fine, but for some strange reason after everything was done and I advanced to the Advanced milestone, it asked me to replace the nozzle with the ContactProbe nozzle, but I did that a few days ago, when the first test release came out. Anyway, I agreed and it asked me to redo the "Calibrate precise camera - nozzle N1 offsets", which I did, but got an error.

The actuator was also configured before.

It now also thinks there's no tip on the nozzle.

In summary, for whatever reason it either lost or overwrote the existing nozzle config.

I'm fixing it manually but though you should know.