Z homing options

[Marius Liebenberg]

Hi All

I have a Peter Betz type dual head. I am looking at the best option for homing the Z axis.

My thoughts are:

1: Put a limit switch on one of the heads and us that in the usual cnc manner to home the Z axis. Dont know how to get the second head homed? Maybe a calculated offset?

2: Put a probe on the machine (there is one anyway) and probe each of the two heads.What happens if there are no nozzles in the heads? What other problems could there be?

Any suggestions please?

[Marek T.]

Do you have Smoothieboard? It seems to me there was some specially modified Smoortie's firmware for Peter's heads.

[Marius Liebenberg]

Yes I have the smoothie and I think I compiled Peter's code as well.

[Marek T.]

So what is the problem? It doesn't work?

If you have original Peter's head - he make his projects very solid and for sure has solved the homing.

If you have some clone - you can still copy his solution :-), isn't it?

[Marius Liebenberg]

Well I did not know that there was a special homing sequence built into his code but I saw the video just now and I will fit a switch to my head. There is not a lot of explanation on how it works so I will have to still gather that.

[Marek T.]

I won't help you, don't have that type of the head. Only knew about that special firmware exists for it.

[Mark]

Hi Marius

 

in my opinion:

 

1.       use the Z-probe on both heads. Save the two Z values.  

2.       If the delta between the two Z values is larger than a certain amount, you know that one or two nozzle tips are not mounted.

3.       If one or two nozzle tips not mounted: Tell the user, abort the homing.

4.       If both tips are mounted: move to the mid-point between the two Z values. Let Z be zero (home Z à G92 Z0).  

 

Cons:

·         You would have to use a custom homing script, I guess. Or add the capability to OpenPNP.

 

Pros:

·         You could use the newest unmodified Smoothieware and benefit from present and future upgrades.

·         You get Z probing in picking and placing.

·         No manual precision part height data entry needed.

·         No problems with feeder Z height inaccuracies.

·         No problems with varying nozzle tip lengths.

 

_Mark

[Mike Menci]

Hello Mark
Can you explain - link to this -;

You could use the newest unmodified Smoothieware and benefit from present and future upgrades.
· You get Z probing in picking and placing.
· No manual precision part height data entry needed.

Thanks
Mike

[Mike Menci]

There is no special code needed All can be done in Smoothie Configuration file but it’s a bit tricky !
Mike

[Marius Liebenberg]

Mark

My next question was gong to be if we cannot integrate the changes Peter made into the latest code but I guess you already dealt with that.

Do you foresee this solution working with a height probe that is not mounted on the heads and then shared like a normal tool setter or must I fit a floating switch to each motor or make each motor float? This will mean that I have to change my head design slightly but it can still be done

[Mark]

> Hello Mark

> Can you explain - link to this -;

> You could use the newest unmodified Smoothieware and benefit from present and future upgrades.

 

As far as I know, the modified firmware for mid-Z-switch homing is more than two years old (June 2016).

https://groups.google.com/d/msg/openpnp/j-M0oRjt-Uk/KSOboB3eAwAJ

There have been important changes in the Smoothieware since.

 

Unfortunately the patch by Jason (that was not integrated) is not compatible anymore.

https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

 

Smoothieware seems to have changed a lot since underneath. It seems that some (or all) of the 6-axis support, and the new end-stops syntax was added later.

http://smoothieware.org/6axis

 

One could still try to re-implement it, of course.

 

 

>   You get Z probing in picking and placing.

>  No manual precision part height data entry needed.

 

Mike, I think we already talked about this. J

 

Adding Z-probing on each pick and each place makes the machine and parts and feeders much simpler to setup, more tolerant to mechanical inadequacies, therefore more reliable.

 

See the last discussion:

https://groups.google.com/d/msg/openpnp/OCEScmV4mic/H7LkRfgSAwAJ

 

See the result:

https://makr.zone/pick-place-machine-first-simulated-small-test-run/66/

 

Note that all credit for the mechanical Liteplacer Z-Probing system that I use must go to Juha!

https://www.liteplacer.com/the-machine/assembly-instructions/pnp-head-step-13-pnp-head-assembly/

 

I’m sure there are more sophisticated solutions like your hall sensor, piezo etc.

https://groups.google.com/d/msg/openpnp/S7pDpZGIjmk/Soa8hZSqAAAJ

 

_Mark

 

[Mark]

> Mark
> My next question was going to be if we cannot integrate the changes Peter made into the latest code but I guess you already dealt with that.

I don’t own a two-nozzle head so I personally don’t need it. I just wanted to point out that a separate Z homing switch is not a must (and that’s true for all numbers of nozzles).

But a while back I looked at the homing code in Smoothieware and I’m sure Jason’s mod could be reintegrated. However I’m not sure it will be accepted this time. I personally made some rather off-putting experience with trying to contribute to Smoothieware.

> Do you foresee this solution working with a height probe that is not mounted on the heads and then shared like a normal tool setter or must I fit a floating switch to each motor or make each motor float? This will mean that I have to change my head design slightly but it can still be done

The real benefit of Z-probing is when probing each and every pick and place. See my previous post with links.

So the probe needs to be integrated into each nozzle. I personally think this could be done much simpler than the Liteplacer by just adding a piezo sensor somewhere, where the mechanical "knock" is "felt" when the nozzle tip hits/picks the part (or when the part hits/places on the PCB).

https://www.youtube.com/watch?v=bPDGMVkTLxU
Can be auto-calibrated and then made quite sensitive:
https://youtu.be/IeIki5_mU2c?t=83
I guess the probe would have to be gated. Whether the "knock" could be detected reliably (no false positives, no false negatives) would have to be determined in the real. :)

_Mark

[Mike Menci]

Marius, 

Here the copy of a part of my configuration for homing:

# Optional enable limit switchedds, actions will stop if any enabled limit switch is triggered

alpha_limit_enable                          true             # Set to true to enable X min and max limit switches

beta_limit_enable                           true             # Set to true to enable Y min and max limit switches

gamma_limit_enable                          false            # Set to true to enable Z min and max limit switches

# Endstops home at their fast feedrate first, then once the endstop is found they home again at their slow feedrate for accuracy

alpha_fast_homing_rate_mm_s                  30              # 50 Alpha/X fast homing feedrate in mm/second

alpha_slow_homing_rate_mm_s                  05              # 25 Alpha/X slow homing feedrate in mm/second

beta_fast_homing_rate_mm_s                   30              # 50 Beta/Y  fast homing feedrate in mm/second

beta_slow_homing_rate_mm_s                   05              # 25 Beta/Y  slow homing feedrate in mm/second

gamma_fast_homing_rate_mm_s                  15              # 10 Gamma/Z fast homing feedrate in mm/second

gamma_slow_homing_rate_mm_s                   3              # 5 Gamma/Z slow homing feedrate in mm/second

alpha_homing_retract_mm                      3               # 3 Distance to retract from the endstop after it is hit for alpha/X

beta_homing_retract_mm                       3               # 3 Distance to retract from the endstop after it is hit for beta/Y

gamma_homing_retract_mm                     -4.35              # -4.35 Z mm  (140)gama max / from switch distance to retract from the end-stop after is hit for gamma/Z

NOTE: One of my Nozzle holder is longer for apx 4mm - this is why I use this Gamma retract 4mm to level up both nozzles to be at the same height HOME !!.  My Homing limit switch is triggered by 2nd nozzle going Down (from Home) ALWAYS and Free going Up from Home position. 

I hope this will help you!

Mike

[SMdude]

Just use a photo diode endstop like it was designed for and use the modified smoothie firmware linked to by Jason in the wiki.

You may have to adjust the z offset after homing.

If you have spring loaded nozzles there is a bit of forgiveness if a part height is not set 100% correct.

[Marius Liebenberg]

Thanks Mike

I assume that you use the latest Smoothie firmware compiled for 6axis CNC is that correct?

Also would you mind sharing your ideas on the hall effect sensor that seems to be integrated with your vacuum housing on the motor. That looks like a doable solution. I dont really want to put together a very elaborate mechanical design on the two heads if I can avoid it. I have problems sourcing such small closed belts over here.

[Marius Liebenberg]

Mark

I fully agree with you that this is the best solution. I however designed my head based on the Peter Betz two nozzle design and I dont have the space to put such a head on. As much as what I love how it works, I am a bit buggered. I hope that Mike will share some of his work based on the hall effect sensor and that might just do it for me.

I am stuck at two places at the moment. One being the vacuum connection and the other is the homing or probing solution. I hope to solve both at the same time.

[Mike Menci]

Hello Gents,
I have no problem sharing my approach on hight sensing and I do hope many of readers will go for it.
From my point of view this feature is essential and it was in Juha’s LightPlacer from the start and Open PnP is missing a lot without it!
I will elaborate in next email (I’m on my mobile phone now) from my home computer with sketches and details!
Cheers!
Mike

Markus - can you post a link where I can see your head with two nozzles how you have it in order to give you some tips how to start with homing?
Mike

[Marius Liebenberg]

Mike This is my setup. The motors are not mounted yet as I have these problems to solve before I start with any design.

I dont know why the photo is always turned on it's side.

[Marius Liebenberg]

[Mike Mencinger]

Hello, 

Here the overview of my sensing system with Juki nozzles (they are all the same length). The compression of nozzle spring pushes the brass tube up and on the top there is a magnet inside the Nema8 top cap. Outside of the cap there is a hall sensor PCB which reacts to change of position of nozzle. Hall can be used on any of free limit switch inputs on Smoothie... 

Any other Questions - Do not hesitate to ask..

Mike

On Wednesday, 31 October 2018 10:57:13 UTC+1, Mike Menci wrote:

Hello Gents,
I have no problem sharing my approach on height sensing and I do hope many of readers will go for it.

[Marius Liebenberg]

Thanks a lot Mike. This is very helpful.

I found a supplier of 3/32" brass tube. That should do am I right?

Wat size magnet did you use. I take it that it would be a neodymium magnet.

[Mike Menci]

Hello
You need to measure the internal diameter of your stepper hollow shaft - it needs to fit in there and make a bit of diameter trim where it will go into Juki body to go all the way inside to thatch the needle top side and still have sufficient ID diameter for vacuum to function onto the needle !
Yes Neodium with hole ! You can not drill magnets so take a bit larger hole and solder a washer on brass tube - this way magnet can not move on tube and it will stick to washer!
The Cap Inside diameter is max size of OD of magnet!
Hall PCB can be lifted or lowered in order to get proper output from Hall sensor.
I hope this answers your questions (for now :-) )
Mike

Mike

[Mike Mencinger]

And fix the Hall to Cap with some screws - needs to be adjustable - slotted holes

something like this 

[Mike Mencinger]

Mark - my configuration file is dated = 26_11_2017 Smoothieboard configuration file, see http://smoothieware.org/configuring-smoothie 

I see above linked Smoothie-ware.org  page has latest update 2017/01/25 14:19 

2017-01-25T14:19:53Z

how to know do I have the latest update or not ? 

Mike

[Marius Liebenberg]

Mike

A couple of questions please.

1: Is the weight of the magnet enough to drive the tube down fast enough?

2: What distance do we need to be from the magnet to the sensor?

3: Is a digital hall sensor good enough or must I do an analog with a compactor or Schmidt trigger

On Wednesday, October 31, 2018 at 4:04:40 PM UTC+2, Mike Mencinger wrote:

[Mike Mencinger]

Marius,

You will need to experiment a bit depending on your speeds...
I purchased my sensors from Tindie:  

CNC test:

Here are the testing results on my CNC router.
Physical distance between Magnet and Hall sensor SMD is ~9.23mm.  This distance will be influenced mostly by the magnet strength and ambient temperature.  If the ambient temperature does not fluctuate significantly then this will not be very critical.  The room temperature  when I tested was 30C  
Travel distance between safe (green) and alarm (red) is 0.776 - 0.778mm.  

• Green: 9.23 mm
• Red:     ~8.453mm
• I used a travel speed 1000 mm/min for these tests.
  
• Considerations that effect these distances
• Magnet Strength (most important)
• Magnet / Sensor position relationship
• Travel Speed: The faster the magnetic field approaches and retracts will have some effect. Keeping this speed consistent during pick and place will make this a minor issue.
  
• Thickness of vacuum wall housing.

My smallest sensor measures about 15.18mm x 14.85mm.  A flat surface would best and you could mount sensor down.  I have attached a graphic.  This has the same circuit as the one on Tindie.  It has a lower profile connecter and uses through hole solder connections.  You could eliminate the connector and solder wires directly to it.
https://www.tindie.com/products/kevpatt/creltek-limit-sensor-343rt/

 

Mike

[Mark]

Hi Mike

 

I would not worry about the config file template version you used. The firmware (.bin) is the important part.

 

Even if you update the firmware afterwards your config file should still work well. All reasonable firmwares will use benign default values for new settings and features. Even if the config syntax itself changes, the old syntax is usually still supported. I know from browsing the source code that Smoothieware does this extensively and well.

 

Example:

Endstop config old style:

http://smoothieware.org/endstops-options

Endstop config new 6axis style:

http://smoothieware.org/6axis#using-additional-axes

 

Just don’t mix them J

 

As long as everything still works after a firmware update, don’t worry! J

 

_Mark

 

 

[Marius Liebenberg]

Hi Mark

I compiled the latest source with the "make all" but I see that one can specify different options. For our purpose, what is the correct option to use?

[Marius Liebenberg]

Thanks a lot Mike.

I like the idea of the sliding mount. That way one can calibrate the position accurately. I will design and build my own little pcb as our postal service in our country is very dysfunctional. If things are not sent via courier it just does not get to you or it takes up a year. I ordered some $8 kits from ebay for my manual paste dispenser in January this year. Still not received them and the chances are good that they are gone :(

[Mike Menci]

I would recommend this Hall :
Sensor Hall unipolar Case SOT23 Range 45÷205 Gauss

Manufacturer HONEYWELL
Sensor type Hall
Sensor type unipolar
Case SOT23
Measuring range 45...205 Gauss
Supply voltage 3...24V DC
Operating temperature -40...150°C
Dimensions see
Additional information
Gross weight 0.06 g
MPN SS343RT

Mike

[Michael Anton]

I planned to do something similar for my machine design, but I wanted to use a linear hall sensor instead.  That way you would have more information than just go/no go.

[Marius Liebenberg]

Agreed. You can tell when the nozzle is in or out and when it is in the probe position. I would also have a comparator on the sensor (LM393) to allow for a very repeatable trip point adjustment for the probing function. The analog signal is used to tell where the magnet is more or less so you can tell if the nozzle is in, down or in probe.

[Brynn Rogers]

If you have a spare ADC channel, linear hall could be helpful.

What will really make prototyping one easier is to get one in a TO-92 package, instead of surface mount.    Make it a lot easier to deal with because it has legs about 30mm long and you can bend it into exactly where you need it much easier than a SMT part stuck on a board.

Brynn

[Mike Mencinger]

Hello Mark, 

From here ? Which one does work with Open PnP?  https://github.com/Smoothieware/Smoothieware/tree/edge/FirmwareBin

I better ask 3x before I make damage!   :-)

Mike

[Michael Anton]

Sorry, I guess I wasn't clear.  I didn't mean an analog hall sensor, but rather one that is a linear position sensor, like the AS5510.  For these sensors, you measure from the side of the magnet, and it measures the position of the field.

[Marius Liebenberg]

My question as well. I compiled the latest code myself and also got all those options. From what I read it might be the firmware.bin file. That is compiled for 3D printing and has 3 axis in the Cartesian space and the rest for extruders. I do believe that we can use the extruder axis to control the nozzle motors.

The CNC variations puts the extra axis also in the Cartesian space at A, B and C axis but this can be controlled by compile options as well.

[Mark]

> Hello Mark,
> From here ? Which one does work with Open PnP? https://github.com/Smoothieware/Smoothieware/tree/edge/FirmwareBin

Well I just always used the newest as linked from here, which points to your link, so yes:
http://smoothieware.org/flashing-smoothie-firmware

Never had an issue on updates. But this is some months ago. No guarantees for the current version. ☺

Later I used my own build from the GitHub sources, last done April 2018. I fixed some issues that are relevant for my machine (PCB conveyor) but not, it seems, for normal OpenPNP. Unfortunately they did not accept my PR for fear the bug fix would break 3D printers/extruders actually *relying* on the bug. I changed the PR to exclude extruders but they still refused it. I think they did not take the time to really understand the bug and the PR.
https://github.com/Smoothieware/Smoothieware/pull/1323

If you look at the rate of third-party PRs being rejected, It's clear that contribution to Smoothieware is ... well, hard. Remember they did equally not accept Jason's perfectly sensible contribution for mid-axis homing.

_Mark

[Mark]

> My question as well. I compiled the latest code myself and also got all those options. From what I read it might be the firmware.bin file. That is compiled for 3D printing and has 3 axis in the Cartesian space and the rest for extruders. I do believe that we can use the extruder axis to control the nozzle motors.

I think this documentation here…
http://smoothieware.org/6axis#compiling-6-axis
… is somewhat misleading.

The normal build will nowadays make a fully capable 5axis firmware, see here:
https://github.com/Smoothieware/Smoothieware/blob/0faa088fe1a2207f6c0b99ec7abccfbd1162f730/src/modules/robot/ActuatorCoordinates.h#L12
config.txt dynamically determines if the two extra axes are handled as extruders or not.

I personally have no use for the CNC option (GRBL mode not needed), if you have a display panel, then perhaps yes:
http://smoothieware.org/cnc-mill-guide#cnc-firmware

_Mark

[Mike Menci]

Thanks Mark, now I’m more confused as earlier :-) - I’m not a software guy so difficult to know which way to go...
I might need to ask on Smoothieboed forum ..
thanks anyway.
Mike

[Marius Liebenberg]

Mike just use firmware.bin for now. I will test mine soon but not right away so I cannot help in the short term. I did read up on the config and the standard code will work.

[Mark]

Hi Mike

 

Sorry I confused you. Just wanted to make my answers correct for all eventualities, but I see now that this is confusing.

 

Trying to make it simpler:

 

·         You have more than 5 axis?
à need to compile your own Smoothieware (I could help).

·         You have a “Peter’s Head” or similar two-nozzle head with mid-axis homing switch?
à need to take Jason’s modified 2016 firmware.

·         Otherwise
à just take the latest edge firmware from the link named here:
http://smoothieware.org/flashing-smoothie-firmware

 

Also:

 

·         Don’t worry about the confix.txt template version you originally used, it ought to be compatible with newer firmware.

·         Don’t worry about the bug I described, as it is not relevant for normal OpenPNP use.

 

_Mark

 

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Mike Menci
Gesendet: Freitag, 2. November 2018 13:15
An: OpenPnP
Betreff: AW: [OpenPnP] Z homing options

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d9048c03-b27e-4259-9d68-fa5816b0bff0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marius Liebenberg]

Mark

Just to be clear. I have a Peter style dual head but going to use probing on both heads. I will fit only one Z homing switch and use the normal Smoothie 5 Axis firmware?

[Mike Mencinger]

Hello, 

I think we need to upgrade Smoothie to get functionality even we do not use more tham 5 axis (for now - but might need more later) ..... 

I just delite bin file on Smoothie Card and copy new bin from here ?- https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware.bin

I will still use my old configuration file (which works fine :-)) so this upgrade will have no influence for now - correct ?

Thanks

Mike

[Arthur Wolf]

Note for the people using MKS, they use the wrong microcontroller ( 100Mhz instead of 120Mhz ) and recently we've gotten more and more reports that it will bug out on MKS with recent firmwares. So maybe don't update if on MKS.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/62edce15-0cda-46ed-9f09-e6206c3d6594%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Mike Mencinger]

And I always try to use my head  :-)     (not Peters  :-) ) works fine / see enclosed

Mike

[Marius Liebenberg]

All those brains and a sense of humor. Impressive :)

[Mark]

 

> Marius Liebenberg:

> Mark

> Just to be clear. I have a Peter style dual head but going to use probing on both heads. I will fit only one Z homing switch and use the normal Smoothie 5 Axis firmware?

 

Marius

 

Yes and no. J

 

Sorry it’s complicated: There’s a bold and a safe way to proceed. Luckily, both ways can be combined J

 

Yes, with the Z probe homing procedure I described earlier (repeated below), you can go forward with the 5-axis off-the-shelf edge firmware. If you have the Z-probes in place on both nozzles, there is no use for a separate Z homing switch and it is not supported by the edge firmware.

 

No, if you want to play it safe, then add a mid-Z homing switch, but add it so it triggers when the nozzles are precisely at the same height.  You then need to use Jason’s 2016 firmware. I doubt this firmware already supports Z-probing as the zprobe Wiki page was only introduced in Jan. 2017.

 

Note that both Z probes must share the same “normally closed” end-stop circuit (open collector) and the same pin on the Smoothieboard, because Smoothieware does only support one Z-probe (as far as I know). However you’d need a separate end-stop circuit for the mid-Z homing switch.

 

If you add both ways physically you can always switch between the two homing methods. Switching the firmware is very quick and easy but it might require separate config.txt and separate machine.xml. You would be veeery future proof this way and you could safely start with the conventional miz-Z homing method (2016 firmware) for now.

 

Be aware, that the new Z-probing homing procedure would need a script. I can help with the Z probing G code but I never wrote a script yet (it seems simple, though).

 

Homing procedure:

1.       use the Z-probe on both heads. Save the two Z values.  

2.       If the delta between the two Z values is larger than a certain amount, you know that one or two nozzle tips are not mounted.

3.       If one or two nozzle tips are not mounted: Tell the user, abort the homing.

4.       If both tips are mounted: move to the mid-point between the two Z values. Let Z be zero (home Z à G92 Z0).  

 

Caveat: As the Z probing homing does not work if nozzle tips are not mounted, you would need to manually mount the tips to begin with and possibly have to edit machine.xml to tell OpenPNP that the tips are mounted (and which one where). Then also never switch off your machine with tips currently unloaded J.

 

 

In the future perhaps the mid-Z homing can be reintroduced in the new firmware so the nozzle tips can be loaded normally.

 

The best future solution would be Z-probing before changing nozzles (off and on). This makes sense for all machines (single nozzle machines too) as brutal collisions with the nozzle tip changer are the most serious “machine breaking” problem in my limited experience. Even tiny errors in Z position will snag the nozzle tip on the changer and very nasty physical things happen! I wasted a nozzle tip holder already and at one time whacked the machine so hard, I had to redo the squaring and lost all coordinate setups in the course (ouch in deed!).  

 

I’m planning to add that to OpenPNP but no promises as to when I find the time.

 

_Mark

 

 

 

[Mike Menci]

Mark please reply to this above - I replace .bin with .bin on Smoothie SD card only ? Correct?
Mike

[Marius Liebenberg]

Mark

Ok I get it now. Not all good news.

I am going to design a little hall effect board that will be able to detect if the nozzle is not installed as well as the probe level. This could be attached to an actuator maybe to raise an error condition that will block the probing or homing functions.

So the probe output will go to the Smoothie input as required and the error signal to another pcb. I have an Arduino that controls the lights and the vacuum sensing that is running under a sub gcode driver. I could sense the errors for the nozzles from there.

Does this make sense?

[Mark]

> Mark please reply to this above - I replace .bin with .bin on Smoothie SD card only ? Correct?

> Mike

 

First, best make a backup of your current firmware.cur and your config.txt.

 

Then go forward as described here:

http://smoothieware.org/flashing-smoothie-firmware#copy

 

You copy the firmware.bin to the card but after it has been flashed to the controller it is renamed firmware.cur

 

So if you later need to go back, rename a copy of your backed up firmware.cur to firmware.bin and repeat.

 

_Mark

[Mark]

> Marius Liebenberg:

> Does this make sense?

 

Hmmm… if you want to hardcode the half travel distance between the two Z probe points then yes. It allows you to go without a script, just G code needed then.

 

NOTE It only works if you don’t have a nozzle tip changer of course, otherwise it would trigger as soon as you unload a tip J

 

If you still want to calculate the mid-point from the actual two Z-probe values then it’s unnecessary, really. When you calculate the distance you can also easily check if the nozzle tips are mounted.

 

Do you actually plan to add a nozzle tip changer, later? Then you’d probably want to support starting the machine without tips.

 

_Mark

 

[Mike Mencinger]

Mark 

There is this configuration adjustment for Level of two Nozzles: 

alpha_homing_retract_mm                      3               # 3 Distance to retract from the endstop after it is hit for alpha/X

beta_homing_retract_mm                       3               # 3 Distance to retract from the endstop after it is hit for beta/Y

gamma_homing_retract_mm                     -4.35              # -4.35 Z mm  (140)gama max / from switch distance to retract from the end-stop after is hit for gamma/Z

NOTE: One of my Nozzle holder is longer for apx 4mm - this is why I use this Gamma retract 4mm to level up both nozzles to be at the same height HOME !!.  My Homing limit switch is triggered by 2nd nozzle going Down (from Home) ALWAYS and Free going Up from Home position. And I have only this homing switch - no others hard-wired.

I hope this will help you as well ....

Mike

[Mike Mencinger]

Mark 

There is this configuration adjustment for Level of two Nozzles: 

alpha_homing_retract_mm                      3               # 3 Distance to retract from the endstop after it is hit for alpha/X

beta_homing_retract_mm                       3               # 3 Distance to retract from the endstop after it is hit for beta/Y

gamma_homing_retract_mm                     -4.35              # -4.35 Z mm  (140)gama max / from switch distance to retract from the end-stop after is hit for gamma/Z

NOTE: One of my Nozzle holder is longer for apx 4mm - this is why I use this Gamma retract 4mm to level up both nozzles to be at the same height HOME !!.  My Homing limit switch is triggered by 2nd nozzle going Down (from Home) ALWAYS and Free going Up from Home position. And I have only this homing switch - no others hard-wired.

I hope this will help you as well ....

Mike

On Friday, 2 November 2018 17:21:32 UTC+1, ma...@makr.zone wrote:

[Mark]

Sorry, Mike, I don’t understand what is your intent with that mail.

 

I think you can’t have negative values. See documentation here:

 

„gamma_homing_retract_mm …  Distance to retract the alpha actuator ( Z axis or gamma tower ) once the endstop is first hit, before re-homing at a slower speed.”

http://smoothieware.org/endstops#configuration

 

_Mark

 

 

Mike Mencinger

[Mike Mencinger]

Sorry my mistake.. 

Earlier with old firmware it was "homing" -horizontal-both nozzles - with new Firmware I get this homing - see picture

Seams I need to play with value in the configuration file "Gamma-homing retract"  to get it beck to home even - horizontal both nozzles 

Mike

[Mark]

> Sorry my mistake.. 

> Earlier with old firmware it was "homing" -horizontal-both nozzles - with new Firmware I get this homing - see picture

> Seams I need to play with value in the configuration file "Gamma-homing retract"  to get it beck to home even - horizontal both nozzles 

 

Mike

 

I think you missed the important fact, that as long as you still want to use the mid-Z-homing switch you cannot upgrade the firmware!

 

You must understand that while one of your nozzles is down, the homing switch signal is constantly engaged. When you switch on your machine and this is the case, Smoothieware cannot home. Jason’s change specifically addressed exactly this issue by first moving out of the switch and only then do the actual homing.

 

If you want to upgrade the firmware, you need to change your homing to the Z probe procedure or something similar.

 

Sorry, I thought I made this very clear, as I wrote:

 

> You have a “Peter’s Head” or similar two-nozzle head with mid-axis homing switch?
à need to take Jason’s modified 2016 firmware.

 

Well as I am writing this, I have a new (old) idea.

 

What happens is you configure your mid-Z-homing switch as a Z probe for now.

 

See here:

http://smoothieware.org/zprobe#configuration

 

Then using a terminal (Pronterface) issue

 

G38.4 Z-40     ; get out of probe signal by max. 40mm

G38.2 Z+40     ; probe Z by max 40mm

G28 Z0         ; set this as home

G28 X0 Y0      ; home X and Y

 

Perhaps you need to reverse the signs (both together) and change the maximum distance.

 

_Mark

 

[Mark]

Sorry a mistake in my G code:

 

 

G38.4 Z-40     ; get out of probe signal by max. 40mm

G38.2 Z+40     ; probe Z by max 40mm

G92 Z0         ; set this as home

G28 X0 Y0      ; home X and Y

 

_______________

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/018b01d472d8%242538aa40%246fa9fec0%24%40makr.zone.

[Mike Mencinger]

Hello Mark

No problem - I don not need those changes - I am fine tuning in 0.2mm already with adjusting gamma_homing_retract   to + value
 this works for me... 

Thanks for your help

Mike

[Mark]

Hi Mike

 

> Hello Mark

> No problem - I don not need those changes - I am fine tuning in 0.2mm already with adjusting gamma_homing_retract   to + value

> this works for me... 

 

Hope you are right. But I have my doubts.

 

1.       Unpower your machine (or just the motors).

2.       Move nozzles to random power-up position by hand

3.       Power machine

4.       Home

 

Do this a few times with different random power-up positions both left- and right-leaning.

 

Homing still accurate?

 

I can image it works if your power-up position is always either left- or always right-leaning. But not both ways.

 

> Thanks for your help

 

You’re welcome! J

 

_Mark

[Mike Mencinger]

Hello Mark 

I reset Smoothie after each change in Configuration and  I do the fine tuning and RE-Open OpenPnP in order to make sure last input to Smoothie configuration is reset-loaded.

My settings and picture of alignment home "0" enclosed (0.1-0.2 off ) 

Thanks

Mike

[Mike Menci]

Hello Mark

You were right - Its not working any more today   :-) 

G38.4 Z-40     ; get out of probe signal by max. 40mm

G38.2 Z+40     ; probe Z by max 40mm

G92 Z0         ; set this as home

G28 X0 Y0      ; home X and Y

I do not have 40 mm stroke on Z    (only 20 mm ) 

Mike

Mike

On Friday, 2 November 2018 20:15:57 UTC+1, ma...@makr.zone wrote:

[Mark]

> I do not have 40 mm stroke on Z    (only 20 mm ) 

 

This is just the maximum distance it probes for the switch to engage. It should actually never be exhausted, so it doesn’t matter if it is too much.

 

The maximum given here will only limit the distance it probes if the stepper or the switch is disconnected or the nozzle is blocked etc.

 

Have you configured the probe? It won’t work otherwise.

 

_Mark

[Mike Menci]

Hello Mark - which parameters need to set in =  "configuration of the probe "  ??

Mike

[Mike Menci]

Hello Mark, 

I did not configure the probe up to now - How if my Z is not homing properly ? First Z home should work -correct ?

Mike

On Sunday, 4 November 2018 11:40:07 UTC+1, ma...@makr.zone wrote:

[Mark]

Hi Mike

 

Z-probe config is here:

http://smoothieware.org/zprobe#configuration-options

 

There are three possibilities:

 

1.       With the new firmware and Z-probe configured: you can connect your mid-Z homing switch as the probe, then you should be able to home using Z-probe G code, see my previous email (below). But no probing on pick&place! It’s just a way to use the new firmware for other benefits than probing.  

2.       With the new firmware and Z-probe configured: you can connect both your hall sensors as Z-probes. Then use a left/right-probing script to calculate the mid-point and to set Z=0 home. See my description earlier in this thread.

3.       With the old firmware: as before with the mid-z homing switch.

 

Hope this helps (have limited time).

 

_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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/21ba5116-33fc-4334-a01a-a2c91ecac4b1%40googlegroups.com.

[Mike Menci]

Thank you Mark - well noted - I try my best... but I need to install my hardware beck up in next days to try this!
Mike

[Marius Liebenberg]

Mark

I have a limit switch on my dual head. I want to do this:

1: Do a Z home to get any known position for one of the heads.

2: Load a nozzle

3: Probe the nozzle at a know location and height.

4: Set the offset for that nozzle

and do the same for the next head and at every nozzle change. Will this be good enough?

On Monday, November 12, 2018 at 11:15:24 PM UTC+2, ma...@makr.zone wrote:

Hi Mike

 

Z-probe config is here:

http://smoothieware.org/zprobe#configuration-options

 

There are three possibilities:

 

1.       With the new firmware and Z-probe configured: you can connect your mid-Z homing switch as the probe, then you should be able to home using Z-probe G code, see my previous email (below). But no probing on pick&place! It’s just a way to use the new firmware for other benefits than probing.  

2.       With the new firmware and Z-probe configured: you can connect both your hall sensors as Z-probes. Then use a left/right-probing script to calculate the mid-point and to set Z=0 home. See my description earlier in this thread.

3.       With the old firmware: as before with the mid-z homing switch.

 

Hope this helps (have limited time).

 

_Mark

 

Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Mike Menci

[Mark]

Marius,

 

first let me remind you, that I don’t have a dual head, so all this is pure theory for me. J

 

I think your method would be the best if you have separate Z actuators that can lower each nozzle independently of the other(s). Then it would actually be brilliant!

 

If however you have shared Z axes (lowering one nozzle will rise the other) then your method would probably create some problems with safe Z.

 

If you calibrate your nozzles individually (like you said in your mail), then safe Z will not necessarily correspond to the same raw i.e. translated Z value for both axes. The nozzles will likely wiggle back and forth, as both Z axes are repeatedly driven to safe Z by OpenPNP. This might also slow down your machine.

 

You could perhaps adjust safe Z each time after your calibration, to reflect the new mid-point.  Or we could change OpenPNP to only drive a nozzle to safe Z if it is currently lower than safe Z.

 

Anyway you’d need a script or change OpenPNP code for your calibration.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b4f102d-f384-489f-8dcb-e6b5b1877e37%40googlegroups.com.

[Marius Liebenberg]

Mark

Thanks for the feedback. One thing is clear, I dont understand the Z axis function properly. So I am almost finished with installing my limit switch for Z axis and then I will play with it to get a better understanding before I inquire again.

One thing I dont get now is how does the system deal with two heads on the same axis. Is one head in the negative space?

[Peter Betz]

Confusing thread for sure. Not sure what the questions are, but...

If you are using my head design, with a mid mount sensor, you need to use the Bin file from Jason's smoothie modifications. I have the bin file on my webpage for the head if you need it. These changes do NOT work with the new smoothie firmware. I looked at it and I am not sure how to change them, I'm an amateur programmer at best. If anyone was able to make the changes required to the new firmware I would be happy to discuss compensating them (free head?? etc.) as the community would likely benefit from it.

This style of homing was developed because it is safer for a head that has one nozzle moving up and one moving down at the same time. It is nearly impossible to crash the head homing with this design. If you want to use the new firmware, you can just install an endstop on one of the carriages and have it home to min or max on one side, easy peazy! I am not sure what the smoothie changes are, or if they are actually important to pick and place, but maybe I will look at adding a hole to my head design to allow you to mount the inductive sensor either in mid mount (and use the old firmware .bin) or at an extent (to use the new firmware version). Of course this is less safe, as you risk colliding with whatever might be under the head at the time (and if you try and home XY to a safe place first you may collide on the drive over there).

Hope this helps.

Peter.

[Mike Menci]

Thank you Peter- well noted.

 I try to use your configuration and go from there. 

I placed a new SD card with your web links download into Smoothie board for tests.

First tests show that homing seams to work for me- let me do some more testing and adjustments. 

For Z probe - http://smoothieware.org/zprobe -might be good to open a new thread. 

Mike 

[Mike Menci]

Hello Peter

Last step in your Web-Page instructions is to change Gcode Default HOME_COMMAND to 

G92.1 
G28 Z ..... 

well this does not work for me 

I change HOME_COMMAND  to:

M999

G1Z0X0Y0F7000

G28 : Home all axes

G1Z0X0Y0F7000

M400 

and for fine tuning now I play with 

config file adding 

gamma_homing_retract_mm                      0.6             #  (140max) gamma distance to retract from the end-stop after is hit for gamma switch/Z

to get both nozzles aligned at Home position perfectly.

Mike

[Marius Liebenberg]

Mike what do you do in the M999?

You can still use the G92 as that just sets the Z value to what you want. It's similar to putting an offset in the config file. It's just easier to do it with G92.

[Mike Menci]

By mistake....
mike

[Marius Liebenberg]

You will battle as that resets the Smoothie :)

On Thursday, November 15, 2018 at 2:20:17 PM UTC+2, Mike Menci wrote:

By mistake....
mike

[Mike Menci]

Yes I noticed that 2 days ago....

[Mike Menci]

So I changed the Home_command to:

G90 

G21 Z0

G1 Z0 

G92.1

G28 X

G28 Y

G92 X0 Y0 Z0

M400

Now it works but ONLY IF MY Z Home position is set to "0" at the Start of Open PnP (when I switch it On) than its OK. 

With other words If my Z is in +XX mm and at Open PnP DRO it is 0 machine thinks that Z is at 0 and It does not look for Zmax switch to check the position!?? 

Why ? 

[Mike Menci]

Enclosed the Log and Gcode export files

Mike

[Marius Liebenberg]

Mike

You are still not doing a probe on the Z axis mate.

G90

G28 Z

G92 Z0

[Marius Liebenberg]

This is s good resource to have on hand

Gcode

On Tuesday, October 30, 2018 at 2:40:52 PM UTC+2, Marius Liebenberg wrote:

Hi All

I have a Peter Betz type dual head. I am looking at the best option for homing the Z axis.

My thoughts are:

1: Put a limit switch on one of the heads and us that in the usual cnc manner to home the Z axis. Dont know how to get the second head homed? Maybe a calculated offset?

2: Put a probe on the machine (there is one anyway) and probe each of the two heads.What happens if there are no nozzles in the heads? What other problems could there be?

Any suggestions please?

[Mike Menci]

Hello 

It seams it is working now with this G Codes:

G90

G28 Z

G92 Z0

G92.1

G28 X

G28 Y

G92 X0 Y0 Z0

M400

Thanks Marius