Dual nozzle setup

[geo0rpo]

Hello friends.

I have setup my machine with cam counter clockwise axis.

Please tell me how can I set the Safe Z of each nozzle?

[Duncan Ellison]

Hi,

In general, with this type of head, both nozzles should have safe Z set to 0.

This ensures that each nozzle returns to the highest position before moving.  There is a theoretical time saving to be gained by allowing the nozzle to be below the highest point during moves, but in the case of your set up, it will make no practical difference.

You should see something like this :

BE AWARE THAT SOME MOVES (MAINLY SET UP ONES) DELIBERATELY IGNORE SAFE Z - SOMETIMES WITHOUT WARNING.

I'm aware that I'm shouting, but this can't be repeated often enough, take care when setting up your machine that you do not manually crash the nozzle until you understand what does what. 

Duncan

[geo0rpo]

The problem is that I cannot set the safe Z value.

It is automatically set to 0 for nozzle N1 and to  -11.846 for N2.

I removed the Z endstop and followed your example of turning off motors so both nozzles settle to 0 with the springs, and then set G92 Z0.

Please tell me, when I press the up arrow in the Z jog should the selected nozzle move up?

Which nozzle should I map to the counterclockwiseAxis? the left or the right?

[geo0rpo]

And when I set the cam wheel radius to 7.5, then the N1 safe Z becomes 7.5 and the N2 becomes -4.346

I am sure I have something wrong in the dual nozzle setup.

[geo0rpo]

Should the  cam wheel radius have the correct value or it should be 0?

[ma...@makr.zone]

Hi geo0rpo

> Please tell me how can I set the Safe Z of each nozzle?

You can't ;-)

You set it on the Z axis, no longer on the nozzle. Why? Because there is actually no degree of freedom between the two nozzles that share one Z axis. The transformation does map one Safe Z to the other and if the two disagree, they fight against each other (this actually happens in older versions).

Safe Z is now also zone, not a single height:

You can use the capture buttons to set the Safe Z Zone.

1. Using jogs, move the first Nozzle to the minimal Safe Z, so it won't collide with anything.
2. Capture the first boundary of the Safe Zone
3. Using jogs, move the second Nozzle to the minimal Safe Z, so it won't collide with anything.
4. Capture the second boundary of the Safe Zone
5. If they are reversed, swap the Z values or repeat with the nozzles reversed.
   

https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--axis-limits

If you have a lot of Z head-room, the machine becomes faster, because it does not need to lift the nozzle all the way. 

More was discussed here:

https://groups.google.com/g/openpnp/c/GtCDy2p8Pbg/m/s1BCwnL_AQAJ

> Should the  cam wheel radius have the correct value or it should be 0?

we discussed about this and the consensus was that only the  Cam Radius should be set. The other two just add constant offsets to the transformation that then must be cancelled in the nozzle offset.

The reason is that the axis reference of Z is the very tip of the nozzle. All the nozzle construction above it is irrelevant.

_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/9614f326-d1af-4d8a-b921-882c19031a58n%40googlegroups.com.

[geo0rpo]

OK, so I just ignore the nozzle safe zone values.

If I set  the cam wheel radius to 0, then when I press "P" in the Z axis, nozzle N1 which is mapped to the counterclockwiseAxis goes to 0 balance point. Both nozzle UP.

But if nozzle N2 which is mapped to the clockwiseAxis is selected then N2 goes down to -11.846

Please look at my machine.xml.

[geo0rpo]

By using the Z axis safe zone, now the Z Park button moves the selected nozzle to the safe value position. OK!

The up arrow Z jog moves the selected nozzle UP. OK

But when I try to pick a part the selected nozzle goes above the part but the other nozzle makes the down move.

What is reversed? I am confused!!!

[geo0rpo]

If we accept that jogging UP the Z axis moves the selected nozzle DOWN then everything is OK!

[ma...@makr.zone]

It seems you have the stepper direction wrong.

What controller do you have?

If Smoothie, you can just invert the dir pin:

http://smoothieware.org/pin-configuration

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ac849b0d-ed73-4f55-95c6-b7cc4b035180n%40googlegroups.com.

[geo0rpo]

I have the smoothieboard with your firmware.

I can just plug the Z axis the other way around.

If I reverse the Z direction then the jog will be OK but the nozzles will be reversed. Instead of N1, the N2 performs the pick position.

[ma...@makr.zone]

Sorry, I don't understand. If jogging is ok, then how can the wrong nozzle pick?

Do you have your Z orientation correct?

Z + must be pointing up in OpenPnP (unlike in the Liteplacer software for instance).

https://github.com/openpnp/openpnp/wiki/Machine-Axes#the-openpnp-coordinate-system

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7be9b642-9807-481f-b9b4-dfce50d3a622n%40googlegroups.com.

[geo0rpo]

And which way is UP? Up for N1 or N2?

If I reverse the Z motor connector so the the selected nozzle moves to the right direction (up-down) with the jog arrows, then when I pick up a part, the selected nozzle goes above the part but the other nozzle performs the pick up movement.

[geo0rpo]

In the video you can see that Jogging the selected N1 nozzle UP moves it DOWN. But when I pickup the part it makes the correct move.

If I reverse the connector or the DIR pin everything gets reversed. Correct jogging but wrong pickup direction.

My son in the background destroying playmobil.

https://www.youtube.com/watch?v=oqyAKMOOUTw

[Mike Menci]

If you Re-name (take the stickers and re-order them N2 =N1  and N1=N2) will than all be OK. Normaly Left Stepper nozzle would be N1 and Right Motor N2  ??

[ma...@makr.zone]

Assuming I see it right:

You got two mistakes:

1. the stepper reversed,
2. your feeder Z is positive, but it must be negative.
   

Z = 0 = both nozzles are up/balanced. So if Z+ points up, then the feeder Z must be below 0 i.e. negative, probably -10.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c9a5d4da-37d2-4ec6-bcfb-2f14e2b7a519n%40googlegroups.com.

[ma...@makr.zone]

Or better yet:

1. Keep the stepper direction as it is
   
2. Swap the labels.
   
3. Swap the nozzle offsets.
   
4. Make the feeder Z negative (-10)
   

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f244941b-71ad-4f75-cd85-f108351cdc05%40makr.zone.

[geo0rpo]

OK, that was the mistake!!! And that was the point I did not understand since the beginning.

Since zero is TOP and Z+ means going UP then in order to go DOWN I should give negative values.

And keep in mind that in the company I work, I once operated an assembleon emerald and positive Z values moved down.

Anyway. Thanks a million!!!

Everything is ok now. I will calibrate for squareness and do some tests.

Thanks again.

[geo0rpo]

As about the Z safe zone, I have it working and both nozzles return to their UP position after picking,

but they do not raise before moving in X-Y. If for example I lower the tip in the tape hole and then move X+, it will just rip the tape.

It should first raise nozzles to the safe zone and then move. Right?

[Duncan Ellison]

Not necessarily,  programmed moves will generally obey the Safe Z  correctly i.e. when running the safe Z zone will be respected.

But when jogging, you are assumed to know what you are doing and you are allowed to crash the head.

There's been a lot of debate here about the wiseness of this, but generally agreed that it must be so to facilitate set-up moves.  

As I said above BE VERY SURE that you will not hit anything before you issue a 100% speed XY move manually.

Duncan

[geo0rpo]

Duncan,

I connected the Zmin endstop again because I am facing the problem that you mentioned, that when the motors are enabled it clicks to the next detent position.

But when I send G28 Z, the Z axis moves to the correct direction but stops before leaving the endstop.

Then I have to send G28 Z again to force it move a little further to clear the endstop and home properly.

Any ideas?

I already increased the endstop.minz.max_travel but did not change anything.

[geo0rpo]

I found this solution based on your idea:

M18 Z ;Turn off Z stepper

G4 S1 ;Wait X seconds

G1 Z15 F300 ;Clear the Endstop

G28 ;HOME

G92 Z0 ;Set Z to zero

G1  Z-6.3 ;Move to balance

G92 Z0 ;Set Z to zero

G92 A0 ;Set N2 rotation to zero

G92 B0 ;Set N1 rotation to zero

[Duncan Ellison]

George(?),

You shouldn't need more than one endstop. That adds an extra layer of complication and a use case that OpenPnP isn't expecting.

There is ONE scenario where this could be useful.  That is checking that BOTH sensors show the nozzles as up before moving, but AFAIK OpenPnP doesn't support that unless you create additional scripting.

The general idea is to do a 'motors off' before you start homing.  This absolutely guarantees that both nozzles are up before moving.  

This is kind of important in the following case :

1) You accidentally jog (or drive) a nozzle below its maximum negative point. 

2) The stepper will slip (lose steps) and OpenPnp (or more accurately your controller) will think the nozzle is somewhere that it is not.

3) You notice this and say 'shoot, now I'll have to do a HOME'.

4) You press home and OpenPnP tries to get you to Safe Z (i.e where the arm is horizontal), but it fails and one nozzle is now still down. 

5) The head move quickly to one (or both) XY endstops to do a home and Presto ... you crash the nozzle into something on the bed.

Have you set the endstop to the absolute top of the travel or somewhere lower ?

[geo0rpo]

I only have one minZ endstop on the right nozzle. In my tests I removed it but now it is connected again.

I set the minZ endstop lower as you suggested and after homing I move back a little up to the balance point.

All is good! See below:

M18 Z ;Turn off Z stepper

G4 S1 ;Wait X seconds

G1 Z15 F300 ;Clear the Endstop

G28 ;HOME

G92 Z0 ;Set Z to zero

G1  Z-6.8 ;Move back to balance

G92 Z0 ;Set Z to zero

G92 A0 ;Set N2 rotation to zero

G92 B0 ;Set N1 rotation to zero

If I just copy the machine.xml to another computer will everything work OK? I am planning to move to the laptop after all is done.

I remember something about an error last time I tried. We shall see...

[Duncan Ellison]

OK, great if that works for you, but I'm a bit confused.

Why are you doing a G1 Z15 F300 ?

Surely this causes the nozzles to make a large excursion, then you are issuing the HOME command and then moving the nozzle again to -6.3 which is presumably a trial and error value.

_Mark's special Smoothie code should be taking care of backing off the endstop (I prefer to call it a Z sensor as it's definately NOT at the end).

You should be seeing it magically back away and then re-home on the sensor, do you not see this ?

Duncan

[Duncan Ellison]

Here's the relevant bit of my config for the Smoothie if it helps :

# Z MIN ENDSTOP

endstop.minz.enable                          true       # enable an endstop

endstop.minz.pin                             1.28!^           # pin

endstop.minz.homing_direction                home_to_max      # direction it moves to the endstop

endstop.minz.homing_position                 -7.750           # the cartesian coordinate this is set to when it homes

endstop.minz.axis                            Z                # the axis designator

endstop.minz.max_travel                      80               # the maximum travel in mm before it times out

endstop.minz.fast_rate                       100              # fast homing rate in mm/sec

endstop.minz.slow_rate                       10               # slow homing rate in mm/sec

endstop.minz.retract                         10               # bounce off endstop in mm

endstop.minz.release_first           true             # first move away from endstop until released

[geo0rpo]

The  "endstop.minz.release_first            true             # first move away from endstop until released "  saved the day! 

Where on earth is this information located?

So I changed to:

M18 Z ;Turn off Z stepper

G4 S1 ;Wait X seconds

G28 ;HOME

G92 Z0 ;Set Z to zero

G1  Z-6.8 ;Move to balance

G92 Z0 ;Set Z to zero

G92 A0 ;Set N2 rotation to zero

G92 B0 ;Set N1 rotation to zero

Should I also set X,Y to zero?

[geo0rpo]

https://www.youtube.com/watch?v=M07_pZEc_lg

[Duncan Ellison]

I guess I should also say that it doesn't matter if you use the 'left' or 'right' sensor, but _Mark's firmware expects to use only one.  

It was initially written for the 'Peter' Head where the nozzles are on a belt and there is no physical block on the travel at the Z=0 point (like you have with the 'China' head. 

To be clear as well about where to adjust the sensor on/off point:

a) Above the physical endstop - no good, you will never get there!

b) At the Balance Point - Not a good idea, it will be unreliable and sometimes you will miss it.
c) A (small) way below the balance point - Good, you will catch it every time and now you know that the nozzle is at an exact spatial point, just work out how far that is off the actual Z=0 point and apply the correction with GCode or (as above) tell Smoothie that when homed Z is actually at, say, -7.750.  Then issue a G0 Z0 to actually move to the balance point.

[geo0rpo]

Yes exactly what I did. A small way below. I understand your point. You are absolutely right.

Just a little different approach, I move back to balance point and set G92 Z0.

It is working good!

Should I also set X+Y to zero with G92?

Thanks!!!

[Duncan Ellison]

Yep, that's how it should look.

The benefit of all this noodling around is that you now have a good grasp of how this is configured and can make small incremental changes if required.

IMHO the Z is not super critical with Juki nozzles due to the spring loading.  Just don't have them crash down into the tape or you will dislodge any parts with no cover tape.

I think setting XY with G92 is probably optional as the homing command should take care of this already.  Don't overthink the relationship between the DRO and the home position, it probably doesn't tally with your understanding, but is probably correct anyway.

Your next decision point should be whether or not to use visual homing(check the Wiki).  You should decide this BEFORE you start remembering any other positions otherwise you'll have to go back and change all the positions of everything if you decide you want this later on.

If you do want visual homing, you will be entering the rabbit hole of fiducial recognition, but this will be very good training for later on.

Duncan  

[geo0rpo]

Yes, I read about it and I understand the point of visual homing.

I think I will pass for now :).

Now I will check and probably calibrate for machine squareness and I do not know yet if I will have venturi or pump.

Also I have already tested fiducials, especially the 1mm round black fiducial printed on white paper is very easy to recognize.

Thanks for all the support.

I will come with more questions and bear with me as Mark commented  (and not bare).

Of I go for squareness!

[geo0rpo]

0.3mm at 260mm is not that bad. Anyway, transform axis did the magic and it is fixed!

[ma...@makr.zone]

>  The  "endstop.minz.release_first            true             # first move away from endstop until released "  saved the day! 

> Where on earth is this information located?

Originally I made a Pull Request here. Unfortunately it was not accepted, so you won't find this in the official documentation. If you're interested, why it was not accepted, follow the discussion here:

https://github.com/Smoothieware/Smoothieware/pull/1423

https://makr.zone/adding-mid-axis-homing-to-smoothieware/359/

Note, a more up to date firmware with more features is here (but I guess you already have it):

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d565e295-011a-4e8e-9ad3-b6d08ddd3c6dn%40googlegroups.com.