Trouble with Smoothie Homing for Peter's Head

[socke]

I'm just building my own machine and run into trouble which I couldn't solve by searching this group. My machine is using Peter's Head and is running Smoothie on a Azteeg X5 GT with TMC2660 stepper drivers. 

So far, x and y axes are running properly but z axis is homing correctly only if the right plate of the head is not on the sensor. If it's on the sensor, a homing command results only in a short movement in the right direction.

I already realized, there is a special Smoothie version for that configuration (for reference: https://github.com/openpnp/Smoothieware/tree/edge/FirmwareBin , original thread here: https://groups.google.com/forum/#!searchin/openpnp/$20Smoothie$20Homing$20for$20Peter$27s$20Head|sort:date/openpnp/QpSp-ONilcM/Cs8WwA7GAwAJ ), which is the same linked on Peter's page.

However, trying to run this firmware leaves my board in a dead condition for unknown reason.

Currently I'm using the latest firmware from the official edge branch, located here: https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware-latest.bin

This version seems to contain the same homing code like the (older) fork from the first link. So I actually can't see any reason why Homing for Peter's Head is not working. Any ideas?

Is there somebody with a similar configuration who already tested this latest firmware?

My config is attached to this post.

Any help would be very appreciated!

[ma...@makr.zone]

I'm still building may machine and I have a single lead screw Z, but I'm using the same Azteeg X5 GT. It works with the latest firmware.bin with one exception (see below).

Have you tried with Pronterface? This usually shows output messages that may give you a clue what's wrong. You can use the M119 code to show the limit switches. Make sure they actually work! With my first board the Z Min switch did not work. It took me a while to realize but the connection from switch header to MCU was simply not there. I ordered a second Azteeg X5 GT (for another reason) and this one worked. The boards show the same silk screen revision but the first one had white pin headers for the motors while the second one had green screw terminals. As you probably have noticed, Panucatt does not respond to any emails.

I used "Red LED" (pin 1.19^) on the EXP1 header as a replacement. See the Azteeg Wiring diagram and here. Need to pullup with the ^ modifier. Although I had no electrical debouncing there, it worked (but then I have LEDs on each endswitch externally, so some capacity is there).

Another bug is this one. If you have endstops on axis B but none on axis A then this will not work with the current Smoothieware firmware. You need to build the fork (like I did) or switch axes, or create pseudo endstops on A with spare pins (nc does not work!).

Hope that helps.

_Mark

[socke]

Thanks for your fast answer!

Yes, I'm using Pronterface - at least for the last few hours. ;-)

My limit switches on x, y, z axes seem to work properly as well. And btw. I'm using optical switches on x and y axes, they also have a red LED for visual indication of their current status, which is very nice to have.

I also enabled all endstops in my config. So the bug you mentioned shouldn't be relevant - right?

I'm afraid regarding the homing behavior your Z axis with leadscrew will be handled different than Peter's Head if your switch is (as usually) located at min or max position of their axis. So if latest Smoothie is working for you, I doesn't mean anything for me - at least in that case.

And yes, I also realized Panucatt is not responding very often to any mails - so most likely it's the last board I bought from them ...

[ma...@makr.zone]

> I also enabled all endstops in my config. So the bug you mentioned shouldn't be relevant - right?

 

Well, I guess you have X, Y, Z with endstops and C1, C2 (internally axis A, B) without, so you're not suffering from this anyway.

A few ideas:

• polarity checked? (normally closed/NC to GND)
  NOTE: if you have both your motor reversed and the polarity of the endswitch wrong, your motor direction may look right when in fact it is the retract move in reverse, as the motor tries to go out of the switch and will stop after only twice the retract length. The Azteec has a peculiar wire order A1 A2 B2 B1 i.e. different than a TinyG.
  
• max_travel enough?
• can you move the axis at all?
• do you have a message in pronterface?
• does the HALT LED blink?
• do you have two endstops (min/max) and have you checked the other one (M119)? 
  
• have you triple checked any screw terminals etc. on the motor wires? (veeery strange effects can happen, if they're half lose)
• because I know it can happen after so many night hours: are you sure you're looking at the right motor and endswitches? :)
• and because it also happened to me: are you sure you tightened the pulley? Motors can be almost silent when moving at homing speeds and in some assembly instruction you're told to leave the pulley loose until the belt has settled it, so easy to forget.
  

Good luck!

[socke]

Thanks for your ideas! For now everything seems to be right, but I will check everything again tomorrow  ...

[socke]

OK, I checked everything again and again. I really think my issue is more related to configuration or software and not hardware/wiring, because homing is working somehow if I set gamma_homing_retract_mm to a larger distance (30mm). But this isn't a permanent solution for me as it could result in collisions with components later. At least I see from these trials, that my sensor is detected.

It could really help me if somebody with Peter's Head and a working configuration could check if homing works with one of the newer firmwares:

https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware.bin

https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware-latest.bin

[SMdude]

As far as I am aware, the only firmware to use for smoothie when using Peters head style setup is to use the modified firmware that Jason made. It should be linked somewhere in the wiki. That firmware works, have you tried it?
https://github.com/openpnp/Smoothieware

[socke]

I already tried this one, but unfortunately it leaves my board dead. Maybe it's has to do something with the Azteeg X5 GT...

[SMdude]

You will have to look at Jasons firmware and see what changes he made, then make those changes to the later firmware and see if it works on that board then.
The changes he made were specifically for the z homing logic. It works on my smoothie.
Failing that perhaps ask the guy who made them?

[socke]

I already did so. I compared the current edge branch with the version Jason made. I found that the file Endstops.cpp is identical in both firmwares, so I suppose homing should work in both versions as well.

But you are right, maybe Jason could answer what's going wrong here?

[ma...@makr.zone]

I think what Jason is describing on the fork notes...

This fork contains minor features that are useful for OpenPnP users. Currently, they are:

• Special handling when homing Z axis for rack and pinion style heads. Will back off of the switch before starting homing if the switch is set when homing is initialized.

... is not done in the standard Smoothieware Endstops::home().

But I think this might not be an endstop in the classical sense at all. It is perhaps rather a Z probe of sorts. Smoothieware has support for that.

It also supports these G38.x codes, i.e. G38.4/G38.5 go away until loss of contact.

(I use this for Liteplacer style Z probing and it works)

[Jason von Nieda]

The changes are very minimal and should be easy to port: https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

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/adbc686b-060a-41a2-85a9-58f4ad1f9378%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[socke]

Thanks Jason. If this is everything to get this feature working, then it should work indeed in the current edge branch and the firmware I'm using.

But do you have any idea, why homing isn't working if I start from the 'wrong' side of the sensor?

[Jason von Nieda]

The rack and pinion homing code in my fork has not been merged to upstream, as far as I know. Without this the behavior you describe is what will happen. If you want to use the latest firmware you’ll need to merge my fork in.

I think you may have made a mistake in comparing the two Endstops modules. They are definitely different.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f79f1a0a-ddc9-4761-8220-9c8f9625a06a%40googlegroups.com.

[socke]

Yes, you are right - it seems I've really made a mistake on comparing, thanks for the clarification!

In fact, both version do not have much in common anymore, I need to check this...

[socke]

In the meantime, I gave the forked firmware another try - but this time it worked! I can only suppose the hangups in my first tries could have to do with my earlier config, maybe some incompatibility...

So homing works for the Z axis now! Thank you guys for all hints and ideas!

However, I just realized that patching the current homing code isn't an easy task for someone like me with no knowledge about the whole system. There are a ton of changes accumulated, not only in the homing code but also in the system around.

Maybe another time or someone else could do it. :-)