Riley

Hmm. Let me know how it goes with new cables. Also, when you went down to 10.0 in/min how did it look? BTW, getting tgFX working right now is a bit tough. I should have some updates with “exes” available soon. If you find any issues with tgfx please open issues via github!

Thanks,

Riley

No I do not think that Windows is your issue. I ran your file just fine.

I am using 370.08 too. What does it do at the n? I am not entirely sure what you are describing.

Riley

I think the G4 is the only way to do this. I am not sure why it would not be efficient. If you know how long the pneumatic operation takes then just use g4 + some fudge room and it should be pretty efficient?

Sfeine,

I am 99.99% sure this is an configuration issue / connection issue.  This is what I want you to do.  set ALL switches to disabled but ONE!

Set these values to DISABLE everything else.

$ysn=0
$ysx=0

$zsn=0
$zsx=0

$asn=0
$asx=0

B and C on TinyG (v1 through v7) do not support switches.

Also 2x verify your $st (switch type) is set correctly.

Lets use the X as our first test case.  This will help us troubleshoot which axis is causing the issue.  You might not be aware but ANY SWITCH that is triggered during a homing operation will fire as if it were the axis being homed.   Meaning if even ONE switch is not wired right or configured right your WHOLE weekend could be ruined 🙂

Set these values for X.  This will be our test axis.
$xsn=0
$xsx=1
To be clear this means that we have our switched wired across the XMAX jumpers.  ALL other switch jumpers are disconnected.  EVEN the xmin jumper.

Ok, whew!  Now we need to attempt to home X.
Issue a:
g28.2 x0

You X axis should move towards your switch.  Note that if it does not you can either change the polarity of your motor in software or reverse the wiring pair on the board motor terminals.

If this works as expected.  Do this whole thing again but enable Y vs X.   In a perfect world you could use that very same switch for all axis’s since you KNOW that it worked right on the X axis.  This would verify that if all homing operations work with this switch being moved to each jumper pair, the switch is good.  Therefore perhaps another switch is not.  I know this is a bit wordy.  If this does not make sense let me know.  Its basically saying we are testing all homing operations with a “known good switch”.  Try this out and let me know how this works.  If it does not work.  I need details.  We will get this working I assure you bud.

Riley

X = min

Y = max

Z = max

In your settings you have this configured for your limit switches.  Is your actual switches wired into this same configuration?

In the past FTDI drivers in windows has caused issues. I am glad you figured it out however.

Riley

I would say this lies outside of “firmware” or “hardware” I set this up now with a red button that kills power to my tinyg.  This way its out side of TinyG and will kill everything without question.

Riley

Just to be clear Alden, on the OpenPNP forum posted this response.  Thanks for the follow up Karl.  You rock.

It’s expected that the search velocity needs to be tuned for the setup, and should be significantly slower than the max velocity. Have you tried using a higher jerk for homing? The homing jerk is independently settable for this purpose. The jerk can actually be set high enough that you lose steps on the decel. This is OK as you are in a homing operation. You would never want to run it this high in actual operation. Please let me know if this gives you more headroom.