Smoothie Homing for Peter's Head

[Jason von Nieda]

Paging Arthur... :)

TL;DR: Can anyone think of a way to tell Smoothie to back off the home switch until it is not tripped, and THEN do the homing sequence? It may need to back off quite far.

So, I'm helping Peter get his rack and pinion drive head going in OpenPnP and we've run into a snag with homing. The home switch is tripped for roughly half the travel of the Z axis which means when we start homing we can't always travel towards the home switch since we may already be past it.

What we want to do is when the homing sequence starts, if the home switch is already tripped, move away from the home switch until it's no longer tripped and then perform the normal homing sequence.

I was thinking we could do this with on the fly configuration hacking, but it seems like that's not possible in Smoothie without restarting between options.

Another option is to have OpenPnP read the state of the switches and then back off in small increments until it's unset, but this requires a level of integration that is not currently easy to do with the GcodeDriver.

Can anyone think of a way to do this with pure Gcode? Right now it looks like our best option is a small change to the Smoothie firmware, but I'd like to avoid that if possible.

Thanks,

Jason

[Henrik]

What DOES it do if the switch is tripped at the start of the homing operation?

If I were to suggest a homing sequence it would be:

1) Move to switch at high(ish) speed (if switch is already active then goto 2)

2) Move off switch at slow(ish) speed.

3) When switch clears you're home.

I mounted my homeswitches mid-travel so the switch is "active" whenever that nozzle is higher than the other. I did it this way because I want to avoid the risk of driving one nozzle down, into something, while homing - which is the risk of having the switch at the very top.

I THEN read the Smoothie docs and from what I could see it wasn't going to work (though I never tried it) so I moved the switches to the top - I'd love to move the back though so I'm following this with anticipation.

Sorry for not being able to actually help :-(

/Henrik.

[Jason von Nieda]

If the switch is tripped at the start the homing operation basically just fails. Smoothie homes like this:

1. Start moving towards home switch at fast speed and stop when it trips.

2. Move back from home switch at slow speed a pre-set amount. Usually like 5mm.

3. Move towards home switch at slow speed and stop when it trips.

So, if the switch is already tripped what ends up happening is #1 is basically skipped, because as soon as it starts moving it sees the switch is tripped. Then we back off, probably not clearing the switch, and then we attempt to move towards the switch again but since it's already tripped nothing happens.

I spoke with some of the Smoothie folks on IRC and it sounds like there's no good way to do this without code, so I wrote a quick patch for it. I'll release it later tonight. There's not much to it.

http://pastebin.com/Qcqk3dmF

Jason

--
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/cd658c25-7bc8-4e69-82df-7dd80d4261ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bryan Mayland]

I ran into this same sort of thing with my printer I built with hall effect endstops. There is a pretty large distance between when the endstop triggers and it would actually physically contact it. The actual bed zero point is in this dead zone so if we start there, step #1 is skipped so it goes to back up *_homing_retract_mm. This config distance must exceed the entire amount of travel that interrupter can pass the trigger point to guarantee that #2 deactivates the endstop (as you know the current code doesn't look for the 'deactive' endstop condition in any of this).

The simple solution is to set your _homing_retract_mm to the total length of your interrupter plus a couple mm. This is safe if this distance is less than half the available travel distance of the axis.

Marlin also has this same behavior so it is somewhat of a common scenario. If Smoothie supported all the crazy GCodes you could do something like

```

M574 Z1 ; set Z endstop active high (normal)

M120 ; enable endstop detection

G1 Z-100 ; move -Z until the endstop is hit

M574 Z0 ; set Z endstop active low (inverted)

M120 ; enable endstop detection

G1 Z100 ; move +Z until the endstop is released

M574 Z1 ; set Z endstop back to active high (normal)

G28 Z0 ; Now home (endstop detection is automatically enabled)

```

I do not believe it supports any of these codes at all though, apart from G1 and G28.

[Peter Betz]

another way to do it is to sense the pinstate first, and switch between home-to-max and home-to-min as required. This would eliminate the need to monitor the pin while you are trying to back out of the switch. It would work the same no matter which way you homed, as long as you were moving in the right direction.

If pin HIGH - set to home-to-max and execute.

If pin LOW- set home-to-min and execute.

Would need to see where the homing direction indicated in the config is loaded into the system and remove that link?

Peter.

[Peter Betz]

you would also need to change the pinstate you are looking for on homing, depending on the direction and also the pin number for home to min and max would have to be the same......

[Jason von Nieda]

Hi folks,

I've checked in a fork of Smoothie that has this new functionality. It's a very small change, so it should be easy to stay up to date with Smoothie on this. If this works well, and if there is interest, I may formalize the function and make it configurable to see if it's something we could merge back to Smoothie eventually.

Commit with code change: https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

Binary: https://github.com/openpnp/Smoothieware/blob/edge/FirmwareBin/firmware.bin?raw=true

To install this, copy firmware.bin to your Smoothie SD card and restart it. It will flash the firmware and rename the file to firmware.cur. By seeing this file you can tell the firmware has been updated.

When you run a home command, if that command includes homing the Z axis, the code will check if the home switch is triggered before starting. If it is it will run the axis away from the switch until the switch turns off, then it will perform a normal homing operation.

Jason

On Thu, Jun 16, 2016 at 1:24 PM Peter Betz <betzt...@gmail.com> wrote:

you would also need to change the pinstate you are looking for on homing, depending on the direction and also the pin number for home to min and max would have to be the same......

--

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/35b15c76-5d19-466b-b02a-22fb71de7600%40googlegroups.com.

[Peter Betz]

Success !!

The head homes as I was hoping it would. This is the safest possible way to home this head design. Thank you very much Jason !!

Here is a video of the head homing from each side of center. As you can see it will always bring the lowest nozzle up. The homing speed is super slow as I crashed the head about 5 times before I figured out the config. 

https://youtu.be/MhU7Ds5ahZk

Peter Betz

BETZtechnik.ca

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/QpSp-ONilcM/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BQw0jz3NBpq-nUasqFKHN9RmJhAd5Pv-FFqyZ6af_91GM1P9w%40mail.gmail.com.

[Henrik Olsson]

Nice work Peter and Jason!

I'll be moving my switches (don't know why I put two in there...) back to mid travel and use the custom Smoothie firmware.

Was/is there anything specific regarding the config that's special for this to work?

Thank you both!

   /Henrik.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/C489705E-EEED-4424-A277-D359EF0B75BB%40gmail.com.

[Peter Betz]

It was just the defining of the signal pin. I know ! Inverts it but I needed to change the ^  to a v. So I think my Z+ was 1.29v! When I was done. I'm assuming that's high vs low but I'm confused about the relationship of that and the !  

Peter Betz

BETZtechnik.ca

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

[Henrik Olsson]

If I understand the docs correctly the ^ activates internal pullup, while v activates internal pulldown. And the ! inverts the "active" state.

So your 1.29v! means that the pin is pulled down, your sensor feeds in a "high" signal when it's active but it's normally "active" so you must invert the state. At least that's how I interpret it. What type of sensor are you using?

There's one issue with having the switch mid-travel - since the home-input is shared with the limit input we lose limit switch capabillity on the head..

/Henrik.

[Joao Matos]

Looking good, hopefully this homing feature can be generalized and pulled back into Smoothie.

Related to the opto switch setup in Smoothie: We were trying to setup our laser cutter homing sequence a couple days ago and were having problems getting the board to correctly recognise the state of the endstop switch (the usual optical style one from eBay). We tried multiple pull up/down settings but nothing worked and after some searches it turns out this style of switch is incompatible with the dedicated endstop pins (at least on MKS SBase board), we had to disable the leds (leds_disable to true in config) and connect the signal pin to one of the pins near the built-in leds.

Just something to be aware.

[Paul Jones]

What config options did you use with this in the endstop section? 

Actually, perhaps a few people with working machines could post their entire smoothie config. Would be helpful for future reference.

Paul.

[Peter Betz]

Hi Paul,

 Sorry for the delay, I was away on a fishing trip. Attached is the config for my MKS SBASE board.

Peter.

[matt]

This reminded me of something i need to figure out.

With Peters head design - is there a way of calculating stepper motor
steps per mm of travel in z axis ?

>>> https://youtu.be/MhU7Ds5ahZk [1]
>>>
>>> Peter Betz
>>> BETZtechnik.ca [2]

>
> --
> 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/2d8edc71-6527-4b16-aa75-96329c3ab463%40googlegroups.com
> [3].
> For more options, visit https://groups.google.com/d/optout [4].
>
>
> Links:
> ------
> [1] https://youtu.be/MhU7Ds5ahZk
> [2] http://betztechnik.ca
> [3]
> https://groups.google.com/d/msgid/openpnp/2d8edc71-6527-4b16-aa75-96329c3ab463%40googlegroups.com?utm_medium=email&utm_source=footer
> [4] https://groups.google.com/d/optout

[Paul Jones]

It's calculated the same way as a belt system. I used an online calculator to estimate what it should be, then measured the actual movement and adjusted as needed. My final number was 80.21

Paul.

> https://groups.google.com/d/msgid/openpnp/4385c645e35080dfa0a7a6a800
> 3607a4%40mattbrocklehurst.co.uk.
> For more options, visit https://groups.google.com/d/optout.

[matt]

Thanks - i'm guessing thats with a 1.8* stepper? I'll obviously
calibrate it was just so i had something sane to start with :D

[Peter Betz]

Hi Paul,

Are you using the new head design already ?

Peter Betz
BETZtechnik.ca

[Paul Jones]

Not quite, I'm still building my machine. I've built the head and it's all moving quite nicely, just waiting on my nozzle adapters and a few other bits.

Paul.

> -----Original Message-----
> From: ope...@googlegroups.com [mailto:ope...@googlegroups.com]
> On Behalf Of Peter Betz
> Sent: Thursday, 7 July 2016 12:38 AM
> To: ope...@googlegroups.com
> Subject: Re: [OpenPnP] Re: Smoothie Homing for Peter's Head
>

> --
> 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/30F76D80-66E1-4E0D-B036-
> C3DC2DD6589D%40gmail.com.