Primary calibration fiducial position and initial camera calibration: default Z bug

[Jan]

Hi all!
My I suggest, that Issues & Solutions point "Primary calibration
fiducial position and initial camera calibration" sets the Z position to
Safe Z instead of 0? I'm redoing this steps at present after optimizing
the down looking camera light and found that the button "Position the
tool over the center of the location" in the "Calibration Rig" section
of the head is an easy way to bring the nozzle in position and/or verify
the position/offsets. I've observed, that Issues and Solutions updates
the X and Y position with the location of the fiducial and sets Z to 0.
I do not understand where Z == 0 is defined/configured but Z = 0 is well
below Safe Z. Hence if I position the nozzle tip over the center of the
secondary fiducial location (which is on an elevated level) the spring
in the nozzle has a hard time...

Jan

[mark maker]

Please read this:

https://github.com/openpnp/openpnp/wiki/Machine-Axes#a-word-about-z-coordinates

If Z is still 0, it means that Z is simply not initialized. That's true for every location in OpenPnP, so changing it in one place will not achieve much.

_Mark

[Jan]

Hi Mark!
Many thanks for your quick response. I've read the article you pointed
to and total agree. Using a right handed coordinate system with z == 0
as the default/homed location makes sense.
Unfortunately I don't yet understand how that translated to my machine
(CMH-T36VA) with am CAM style head. I see two derived Z axis on my
setup, CamCounterClockwise and CamClockwise. This are assigned to the
two nozzles Z Coordinate System both with a Offset of 0. I can change
the offset such that Z == 0 when parked. Is that what I have to do? (I'm
sorry for asking this questions, I've started using the machine.xml
Nelio posted last year and Issues and Solutions says "Milestone Advance"
and presents some Issues with Severity "Fundamental" is "Include Solved"
is checked.)

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

I am not the only one that can answer such questions, especially such general questions. Please somebody else explain it to Jan.

_Mark

[bert shivaan]

So I can't say I truly understand what the question is, but here are some thoughts:

Cam style heads still treat both nozzles as separate nozzles. So maybe you are confused thinking about the position of a nozzle that is down with the one that is up? So if the right nozzle is the focus, that is what the DRO is showing. OpenPNP knows where the left nozzle is, but you don't need to. Does this even come close to the question?

As for the issues and solutions, I would think with what I have been reading for the past year with what Mark has done overall, and now Tony with vision stuff, You should likely start with a fresh install and not try to use a machine from someone else. That way everything will get set up correctly with respect to YOUR machine.

Side note to both Mark and Tony, I do not mean to miss credit for all either of you have done for this project. To be honest I have been truly overwhelmed with the progress you guys have made and am unable to keep up with who did what. I just know you have BOTH done some amazing things!!

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/5c444880-3820-5849-c578-11483e87a161%40makr.zone.

[Jan]

Hi Bert!
Many thanks for your response! According to Marks response, I actually
have a Z problem in my setup. So my question is, how/where is/should the
Z offset of the nozzle be configured?
Background: I have a CHM-T36VA. Its exactly the same hardware has many
others have, so I thought it would be a good idea to start from someone
else's machine.xml to get all the axis, head, driver, gcode stuff setup
well. I then followed Marks advice closely to reopened all solved and
dismissed solutions to make sure everything is correctly setup and to
learn whats happening under the hood. (I also agree, that it would be
best to start from scretch but did not do that yet as there are to many
gcode/axis configurations I would have to copy over.) Then I lost a
nozzle because of a bad Z setup. So I reopened every again and tried to
understand why Z is wrong. I found the axis and their setup I expected
from reading the Wiki about Cam style heads. My Z axis is mapped to a
motor that homes in the center. This axis can be moved to both
directions and the limits correspond to the angle the bar mounted on the
motor shaft can be tilted until it hits a mechanical limit. Next I have
a CamCounterClockwise axis which translates this angular motion into a
linear. This axis is then used to operate nozzle N1. N1 has its
coordinate system set to Z offset = 0. If I select Nozzle N1 in Machine
Controls, DRO says Z = 9.0mm (directly after homing, nozzle full
retracted, M114 reports Z = 0.0), which is obviously my problem. In the
meanwhile I found out, that I can use the Z-offset of the nozzle to
shift Z, but that feels like hiding the actual problem. So I like to
understand where this Z-offset is coming from. I've attached my
machine.xml, in case you'd like to take a look. Please note, that I
configured the Z-Offset for N1 to -8.27mm to compensate the offset
temporarily.

Jan

>>> <mailto:openpnp+u...@googlegroups.com>

>>> <mailto:openpnp+u...@googlegroups.com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone
>>> <https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone>

>>> <https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone?utm_medium=email&utm_source=footer>

>>> <https://groups.google.com/d/msgid/openpnp/aade66c0-933c-e2ca-8d74-142e30e0a343%40makr.zone?utm_medium=email&utm_source=footer>.
>>>
>>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/5c444880-3820-5849-c578-11483e87a161%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/5c444880-3820-5849-c578-11483e87a161%40makr.zone?utm_medium=email&utm_source=footer>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzbMF498pZmOSriEFESVyLJpxUfBxeL7Mo9GKwWM_KSEQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzbMF498pZmOSriEFESVyLJpxUfBxeL7Mo9GKwWM_KSEQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[mark maker]

> So I can't say I truly understand what the question is

Now that I re-read the question, I have to agree.

@Jan, please reformulate the question. Does the machine not work as expected? In what way? Or is this just a question for understanding how things work?

> You should likely start with a fresh install and not try to use a machine from someone else.

I would normally agree, but in case of the CMH-T36VA this might be different. This is supposed to be a standardized off-the-shelf machine, so another user's machine.xml should actually work. And there might still be stuff, that needs to be a bit special, i.e. is not (yet) automatically covered by Issues & Solutions (or actually wrong, like the serial flow control).

> Side note to both Mark and Tony, I do not mean to miss credit for all either of you have done for this project. To be honest I have been truly overwhelmed with the progress you guys have made and am unable to keep up with who did what.

I can imagine that it can appear overwhelming. Especially as we are mostly discussing evolving ideas, bugs and problems, often in many iterations. And once the solution is mature, only very few users come to this list to say "hey, I just setup my machine and everything went well". That's probably why the bugs and problems, the appearance of instability, tend to stick in the heads of people, long after actually having been eliminated. It is unfortunately the same with every software I'm involved with.

But: most of what Tony, Karlinik and me added was actually aimed at simplifying things, and/or making them more reliable, more robust, more precise. Most of the complexities are now completely hidden away behind the scenes. They had to be discussed and developed here on the list, sometimes with difficulties, yes, but now they are often tucked away behind a simple Issues & Solutions Accept button.

Sometimes it seems to me that the largest problem nowadays is for users to let go and trust Issues & Solutions. 😁

_Mark

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

[Jan]

Hi Mark!
Please see my post an hour ago. This hopefully clarifies my question.
In the mean while, I really like Issues & Solutions and it is very easy
for me as ape to use it. However, there are points, where a
recommendation would be very helpful like the fix/dynamic safe-z
decision. From reading this list for a while now, I know that I'm not
the only one seeking for advice and you always respond, that dynamic is
recommended, but one shall be aware of the hang loose movements that
involves.
I also like to help improving Issues & Solutions to encourage other
CHM-T users to do the conversion. Unfortunately just recently someone
reported, that he reverted to the Chinese software because he crashed a
nozzle. To understand his problem, I really like to know where my Z
problem is. Afterwords I'll add a response to put the thread back into a
pro OpenPnp state so that future readers do not get scared.

Jan

On 19.01.2022 10:02, mark maker wrote:
> />//So I can't say I truly understand what the question is/

>
> Now that I re-read the question, I have to agree.
>
> @Jan, please reformulate the question. Does the machine not work as
> expected? In what way? Or is this just a question for understanding how
> things work?
>

> /> //You should likely start with a fresh install and not try to use a
> machine from someone else./

>
> I would normally agree, but in case of the CMH-T36VA this might be
> different. This is supposed to be a standardized off-the-shelf machine,

> so another user's machine.xml /should/ actually work. And there might

> still be stuff, that needs to be a bit special, i.e. is not (yet)

> automatically covered by Issues & Solutions (or actually /wrong/, like
> the serial flow control).
>
> /> //Side note to both Mark and Tony, I do not mean to miss credit for

> all either of you have done for this project. To be honest I have been
> truly overwhelmed with the progress you guys have made and am unable to

> keep up with who did what. /
>
> I can imagine that it can /appear/ overwhelming. Especially as we are

> mostly discussing evolving ideas, bugs and problems, often in many
> iterations. And once the solution is mature, only very few users come to
> this list to say "hey, I just setup my machine and everything went
> well". That's probably why the bugs and problems, the appearance of
> instability, tend to stick in the heads of people, long after actually
> having been eliminated. It is unfortunately the same with every software
> I'm involved with.
>

> *But*: most of what Tony, Karlinik and me added was actually aimed at
> /simplifying/ things, and/or making them more reliable, more robust,

> more precise. Most of the complexities are now completely hidden away
> behind the scenes. They had to be discussed and developed here on the
> list, sometimes with difficulties, yes, but now they are often tucked

> away behind a simple Issues & Solutions *Accept* button.

>
> Sometimes it seems to me that the largest problem nowadays is for users

> to /let go/ and trust Issues & Solutions. 😁

>> <https://groups.google.com/d/msgid/openpnp/5c444880-3820-5849-c578-11483e87a161%40makr.zone?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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/CA%2BKNHNzbMF498pZmOSriEFESVyLJpxUfBxeL7Mo9GKwWM_KSEQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzbMF498pZmOSriEFESVyLJpxUfBxeL7Mo9GKwWM_KSEQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/599c3443-3c08-1c5d-db29-c49aba362706%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/599c3443-3c08-1c5d-db29-c49aba362706%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan,

First make sure your setup is neutral:

1. Set the two nozzles' head offset Z to zero.
2. Set any CamCounterClockwise gap and wheel radius to zero.

The Z homing switch might have a certain one-sidedness. So controller Z=0 is not necessarily the true balance point. This can be obscured if the nozzle retraction is limited by a bar (the spring pull being blocked) this may mean that the axis has a "dead zone", where both nozzles are blocked i.e. the motor can move a bit before either nozzle is pushed down.

But as long as the nozzles are both balanced (springs blocked by the bar), this is not actually important. It will be compensated by the "Nozzle N2 offsets..." Issues & Solutions step:

Having said that...

If it is very important to you to have the machine balanced even on the G-code/controller level, here is a procedure to balance it:

1. Set the two nozzles' head offset Z to zero.
2. Set any CamCounterClockwise gap and wheel radius to zero.
3. Home the machine.
   
4. Jog the nozzles down to a common flat Z table surface, one after the other, both times reading off the controller Z coordinate by M114 (use the console tab in the driver).
   
5. Divide the sum of the two read-off Z coordinates (one negative, one positive) by two.
6. Set this as the new homing coordinate in the config.txt of the controller, probably to gamma_min.
   
7. Reset the controller and home the machine.
   
8. Repeat step 4. It should now show a balanced machine, i.e. the two Z coordinates should read approximately the same (in the DRO, or in absolute controller coordinates) when each nozzle tip touches the common table surface.
   
9. Follow Issues & Solutions to setup Dynamic Safe Z and capture both Safe Z as low as possible, at least at the point where the spring is blocked by the bar. This will optimize motion planning, i.e.  the time traveling in X/Y will be used to traverse the "dead zone" I mentioned. You might need to re-open these solutions, i.e., enable the Include Solved? checkbox and press Reopen on these.
   
10. Also do the "Nozzle N2 offsets..." Issues & Solutions step as shown in the screen-shot above.Again, you might need to re-open the solution. It should now record a near-zero Z offset.

_Mark

[mark maker]

> However, there are points, where a recommendation would be very helpful like the fix/dynamic safe-z decision. From reading this list for a while now, I know that I'm not the only one seeking for advice and you always respond, that dynamic is recommended, but one shall be aware of the hang loose movements that involves.

I'm a bit confused what you actually want it to do.

> To understand his problem, I really like to know where my Z problem is.

See the other reply. I'm confident that when correctly configured, there will be no such problems.

_Mark

[Jan]

Hi Mark!
Many thanks for your detailed response.
I tried the following:
a) changed both nozzle Z-Offsets to 0
b) used I&S to configure both nozzles for dynamic Safe-Z and use the
homed position (fully retracted) as Safe-Z (first guess, can/will change
later)
-> DRO reports a large positive Z (9mm) for N1 and N2.
c) set Cam Wheel Radius and Gap to zero. (For others read this: its ok
to do that, even if it does not represent the physical nature of the
head because the wheel and gap only add a constant offset in Z. This is
only relevant for the absolute Z position of the nozzle. In real life
everything is relative to teached in positions like PCB-Z, Safe-Z.)
-> DRO reports now Z = 0 for both nozzles -> problem solved, many
thanks! (btw: the Nozzle position z = 9, I've seen before c, corresponds
exactly to Cam Wheel Radius + Cam Wheel Gap)

Now the homing offset you pointed out (I actually thought I'd put that
into an other thread once this has been solved): First, I think I need
it, because after homing one nozzle is still not fully retraced. I
suspect, that I might change the Z position when manually inserting a
nozzle tip. Second, the CHM-T firmware is a smoothieware port with a
hard-coded configuration file. (the hardware does not have a card
connector hence the configuration file is part of the binary) Changing
the binary is a lot of work and probably not many people are willing to
do that. We/I therefore need/seek for a solutions with just gcode from
within OpenPnp. Yesterday I searched around and found
a) there is a field "Home Coordinate" on the primary Z-Axis. This seems
to be not used.
b) I found, that smoothieware supports M206 to set a homing offset and
G92 to apply a general offset. I'd put one of this into the enable or
homing command.
What is your suggested solution?

Jan

On 19.01.2022 10:56, mark maker wrote:
> Hi Jan,
>
> First make sure your setup is neutral:
>

> 1. Set the two nozzles' head offset Z to zero.
> 2. Set any CamCounterClockwise
> <https://github.com/openpnp/openpnp/wiki/Transformed-Axes#referencecamcounterclockwiseaxis>

> gap and wheel radius to zero.
>

> The Z homing switch might have a certain**one-sidedness. So controller

> Z=0 is not necessarily the true balance point. This can be obscured if
> the nozzle retraction is limited by a bar (the spring pull being
> blocked) this may mean that the axis has a "dead zone", where both
> nozzles are blocked i.e. the motor can move a bit before either nozzle
> is pushed down.
>
> But as long as the nozzles are both balanced (springs blocked by the
> bar), this is not actually important. It will be compensated by the
> "Nozzle N2 offsets..." Issues & Solutions step:
>

> Having said that...
>
> If it is very important to you to have the machine balanced *even on the
> G-code/controller level*, here is a procedure to balance it:
>
> 1. Set the two nozzles' head offset Z to zero.
> 2. Set any CamCounterClockwise
> <https://github.com/openpnp/openpnp/wiki/Transformed-Axes#referencecamcounterclockwiseaxis>

> gap and wheel radius to zero.

> 3. Home the machine.
> 4. Jog the nozzles down to a common flat Z table surface, one after the

> other, both times reading off the controller Z coordinate by M114
> (use the console tab in the driver).

> 5. Divide the sum of the two read-off Z coordinates (one negative, one
> positive) by two.
> 6. Set this as the new homing coordinate in the config.txt of the
> controller, probably to gamma_min.
> 7. Reset the controller and home the machine.
> 8. Repeat step 4. It should now show a balanced machine, i.e. the two Z

> coordinates should read approximately the same (in the DRO, or in

> /absolute/ controller coordinates) when each nozzle tip touches the
> common table surface.
> 9. Follow Issues & Solutions to setup Dynamic Safe Z and capture both

> Safe Z as low as possible, at least at the point where the spring is
> blocked by the bar. This will optimize motion planning, i.e.  the
> time traveling in X/Y will be used to traverse the "dead zone" I
> mentioned. You might need to re-open these solutions, i.e., enable

> the*Include Solved?* checkbox and press *Reopen* on these.
> 10. Also do the "Nozzle N2 offsets..." Issues & Solutions step as shown

> https://groups.google.com/d/msgid/openpnp/8d6f775b-f350-9f02-7092-9610f0553e03%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/8d6f775b-f350-9f02-7092-9610f0553e03%40makr.zone?utm_medium=email&utm_source=footer>.

[Jan]

On 19.01.2022 11:37, mark maker wrote:

> /> However, there are points, where a recommendation would be very

> helpful like the fix/dynamic safe-z decision. From reading this list for
> a while now, I know that I'm not the only one seeking for advice and you
> always respond, that dynamic is recommended, but one shall be aware of

> the hang loose movements that involves. //
> /

>
> I'm a bit confused what you actually want it to do.
>

I'd like Issues & Solutions to recommend dynamic safe Z if that's what
your expert guys recommend when asked. For visual homing there is
already a recommendation for ResetToFiducialLocation. In general I'd
like Issues & Solutions to give instructions, like it already does in
most placed. Just where the user has to make decision, the recommended
one should be marked as such; or even just provide only this. Everything
can be changed manually later anyhow. So you might help yourself if you
put in your recommendations and remove the decision the user can't make
without fully understanding all its consequences. Apes like me wont
quick process and you experts do not wont to answer the same questions
over and over again. Issues & Solutions is the perfect way to help apes
to setup their machine and later monitor if everything is still as it
should be.

> /> //To understand his problem, I really like to know where my Z problem
> is./

>
> See the other reply. I'm confident that when correctly configured, there
> will be no such problems.
>

Yes, it is. Seems that the original setup by Matt already has Cam Wheel
Radius = 8.5. Looks like this is a serious issue between
CamCounterClockwiseAxis and the default Nozzle Z-Offset of 0 as it
degrades your commend, that Z == 0 is always assumed to be safe. If you
just configure your CamCounterClockWiseAxis as it physically is (with
cam wheel radius > 0) and add a Nozzle with default z-Offset == 0, you
end up with a Z > 0 for the homed nozzle. If in addition Safe-Z is not
correctly set (to a value with Z > 0) it's likely that you crash your
nozzle. Btw: could it be, that the machine always drives to Safe-Z first
before moving in X/Y even if Z > Save-Z? If the machine only moves to
Safe-Z if Z < Safe-Z there would be no problem. However, it still would
not follow the OpenPnp philosophy that Z == 0 is safe.

Jan

> https://groups.google.com/d/msgid/openpnp/34acfabd-224b-3f02-3bdb-6a8bf661cd74%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/34acfabd-224b-3f02-3bdb-6a8bf661cd74%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

> Changing the binary is a lot of work and probably not many people are willing to do that

Yes you can use

G92 Z<value>

in your HOME_COMMAND, after G28, with <value> from step 6 of my procedure.

Or

M206 Z<value>

before G28, but I never used that, and I'm not sure of the sign of the offset, maybe it would be

M206 Z<-value>

_Mark

[mark maker]

> Seems that the original setup by Matt already has Cam Wheel Radius = 8.5

The Cam Wheel Radius and Gap are actually something I'd like to remove, because AFAIK all they add is confusion. Like I wrote here:

Cam Wheel Radius and Cam Wheel Gap are physical properties of the mechanics. However, they both just add a constant offset to the transformation. Because we relate the target Z coordinate to the nozzle tip rather than the nozzle back (where the cam wheel pushes it), such an offset is not purposeful and you will simply end up compensating for it in the nozzle offset. Leave both at zero.

https://github.com/openpnp/openpnp/wiki/Transformed-Axes#referencecamcounterclockwiseaxis

The problem: The cam transform code is originally by Jason, creator of OpenPnP, and I'm not entirely sure if there isn't a hidden purpose for these offsets, that I didn't think of so far.

😮 Now that I said all that... I think I can now see how a non-zero Cam Wheel Radius and Gap can indirectly create a crash with Issues & Solutions. The "Nozzle N1 offsets" solutions will reset the Z offset to zero, taking away the  Cam Wheel Radius and Gap compensation, that I mentioned in the Wiki! I will add some form of safety net there.

> Looks like this is a serious issue between CamCounterClockwiseAxis and the default Nozzle Z-Offset of 0 as it degrades your commend, that Z == 0 is always assumed to be safe.

Strictly speaking it is not "always assumed to be safe". Properly written code in OpenPnP must always explicitly look at the Safe Z of the given HeadMountable, and never make any other assumption about Safe Z. Otherwise, it is a bug!

BUT: It is just a fact that Z=0 is the default/initialization coordinate of any location in OpenPnP, so if the user forgets to set Z up, before using that location, a crash can happen! That's why I recommend that Z=0 happens to be a safe coordinate. If you are a "perfect user" that never forgets anything, you can use Safe Z above 0. OpenPnP is intended to support that, any bugs will be fixed!

Note, that safe Z can be well below Z=0. For instance, a Liteplacer typically has an insanely large Z head-room, and a relatively slow Z axis. Therefore it is recommended to set the Safe Z as low as possible for better speed. On my machine it is at -25mm or something like that. So again, properly written code must always explicitly look at the Safe Z of the given HeadMountable, or it will spoil that optimization!

https://github.com/openpnp/openpnp/wiki/Machine-Axes#a-word-about-z-coordinates

_Mark

[Jan]

Hi Mark!

On 19.01.2022 14:07, mark maker wrote:
> /> Seems that the original setup by Matt already has Cam Wheel Radius = 8.5/
>
> The *Cam Wheel Radius* and *Gap* are actually something I'd like to

> remove, because AFAIK all they add is confusion. Like I wrote here:
>

> /*Cam Wheel Radius*//and //*Cam Wheel Gap*//are physical properties of

> the mechanics. However, they both just add a constant offset to the
> transformation. Because we relate the target Z coordinate to the nozzle

> //*tip*//rather than the nozzle //*back*//(where the cam wheel pushes
> it), such an offset is not purposeful and *you will simply end up
> compensating for it in the nozzle offset*.Leave both at zero./
>
> https://github.com/openpnp/openpnp/wiki/Transformed-Axes#referencecamcounterclockwiseaxis
>
Sorry, I've overlooked this section...
Removing it might call problems on existing setups, as the
transformation changes Z and hence removing it will change all Z locations.

[...]
> /> //Looks like this is a serious issue between CamCounterClockwiseAxis

> and the default Nozzle Z-Offset of 0 as it degrades your commend, that Z

> == 0 is always assumed to be safe./
>
> Strictly speaking it is *not* "always assumed to be safe". Properly

> written code in OpenPnP must always explicitly look at the Safe Z of the
> given HeadMountable, and never make any other assumption about Safe Z.
> Otherwise, it is a bug!
>

Actually I don't remember exactly under which conditions I crashed a
nozzle. It was with the Cam-Radius > 0, but also also might have
temporarily switched off the Safe-Z or configured it to 0. Many
secondary calibration fiducial is 3mm higher then the first, maybe
save-Z was at PCB level at that time. I do have the logs but it's
probably not worth looking for as long as the operate is the problem...

Jan

> https://groups.google.com/d/msgid/openpnp/d234ac60-01e1-8f74-812e-4bb4ab131817%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/d234ac60-01e1-8f74-812e-4bb4ab131817%40makr.zone?utm_medium=email&utm_source=footer>.

[Jan]

Hi Mark!

On 19.01.2022 13:11, mark maker wrote:
> /> //Changing the binary is a lot of work and probably not many people
> are willing to do that/

>
> Yes you can use
>
> G92 Z<value>
>
> in your HOME_COMMAND, after G28, with <value> from step 6 of my procedure.
>

Many thanks! That works very well.
There is just a minor issue concerning G92 I just noticed: If Save-Z is
higher then the offset I apply (Z after mechanical homing is < Save-Z)
the machine does not move to the fiducial for visual homing. It throws
an error indicating, that it can't move to a negative X value. I guess I
found the reason in the logs: after visual homing, OpenPnp uses G92 to
apply the offset to X and Y but does not revert it when rehoming. So on
the second homing cycle there is still a offset applied. In my case, the
very first move to is to raise Z to Save-Z. This move fails because with
the offset applied X gets negative. A simple G92.1 as first command in
HOME_COMMAND provides a workaround, but covers it not correctly. As
OpenPnp applies the offset as part of the visual homing, its to my
understanding OpenPnps responsibility to remove it when rehoming.

Jan

> https://groups.google.com/d/msgid/openpnp/89647da1-c9f6-ebff-2c4b-5a910cc328e6%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/89647da1-c9f6-ebff-2c4b-5a910cc328e6%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hmmm. This should work. HOME_COMMAND should only set Z. Visual Homing should only set X, Y.

If you have ResetToFiducialLocation as the visual Homing Method, you should also be able to re-home many times.

I assume you have C-riegels firmware, with the port of my PnP patches applied, right? This is absolutely needed!

_Mark

[Jan]

Yes, I've c-riegels firmware and modified it to fix some issues (blower
burn out, drag pin burn out, vacuum pump power can be adjusted) I'll
create a PR for in the next days.
No, unfortunately I can only home once (or after applying G92.1) under
my special conditions: I applied a Z offset after mechanical homing
which leaves Z < Save-Z. Please see the attached log. It contains three
homing cycles, first is preceded with a G92.1 and is successful. Second
follows immediately and fails. Third is again preceded with a G92.1. To
my understanding the first move after mechanical homing is to bring the
nozzle to Safe-Z. This move is affected by G92 applied after previous
visual homing and fails because in sum tries to machine the machine into
negative X, which is beyond the lower limit.

Jan

> https://groups.google.com/d/msgid/openpnp/76bd342b-3616-5601-95ab-8f76441498d8%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/76bd342b-3616-5601-95ab-8f76441498d8%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

In your log the G28 will AFAIK reset the G92 Z2.4 before it.

Try this

G28 Z2.4
G28 X0 Y0

G28 actually allows you to specify the coordinate to which to home. So no G92 needed. 😁

_m

[Jan]

On 19.01.2022 18:42, mark maker wrote:
> In your log the G28 will AFAIK reset the G92 Z2.4 before it.
>
> Try this
>
> G28 Z2.4
> G28 X0 Y0

This does not work on my firmware. If I manually send "G28 Z2.4" and
then read the position using M114 Z is 0.0. With my version:

G92.1
G28 Z
G92 Z2.4
G28 X Y

the offset is correctly compensated.

Jan

> https://groups.google.com/d/msgid/openpnp/a005bcc6-e575-e098-5b48-3930701218e7%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/a005bcc6-e575-e098-5b48-3930701218e7%40makr.zone?utm_medium=email&utm_source=footer>.