Linking two gantry joints with homing switches so it unracks on home

More
22 May 2022 12:15 #243552 by tommylight

What  I mean, if you start with -2, then isn't the sequence -2,-1,0,1,2....

Nope, that will not work.
The sequence is 0,1,2,3.... but any of those has a - means it is tandem and has another joint attached to it.
So, 0,1,-2,3
or 0,-1,2,3
or 0,1,2,-3
are all correct.
Rod's logic is right, but in this case the - is used to mark a tandem axis.

Please Log in or Create an account to join the conversation.

More
22 May 2022 12:18 #243553 by tommylight

This is the confusion I see. -2 is illegal by my read.

[/quote]
It is not, all my machines have -2 for Y axis joints, the gantry is still inside the shop! :)

Please Log in or Create an account to join the conversation.

More
22 May 2022 13:44 #243558 by snowgoer540

What  I mean, if you start with -2, then isn't the sequence -2,-1,0,1,2....


I think the part that has gotten skimmed over is: The absolute value of sequence numbers must increment by one — skipping sequence numbers is not supported.

so on one config of mine with YYXZ, I have HOME_SEQUENCE of -1,-1,1,0 which has worked for 5 years and complies with the docs..

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.

Please Log in or Create an account to join the conversation.

More
22 May 2022 19:05 - 22 May 2022 19:06 #243568 by rodw
OK, homing.c works with absolute values for home sequences but this statement is incorrect.

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.

Z homes, X homes, then Y the synchronised axis homes last.
I am guessing pncconf uses -2 in the mistaken belief that it is required for the gantry to home last.
I do find this very confusing.
Its interesting that the behaviour and/or documents have changed over time since I was arguably the first to adopt the new joint axes features on a gantry machine when released into master branch back when v 2.8 was master branch.

But we've been sidetracked. Why must a synchronised axis not support jogging before homing AND respect the synchronised HOME_OFFSET? eg you jog Y1 nad Y2 moves with it. I am struggling to think of a use case where this would be dangerous.... Maybe there is room for another change here.
[/quote]
Last edit: 22 May 2022 19:06 by rodw.

Please Log in or Create an account to join the conversation.

More
22 May 2022 19:26 #243572 by tommylight
Joint mode = means controlling joints, and as such Y1 and Y2 are not the same thing, each has it's own ... everything.
As for understanding, i am not understanding why is this subject still going on, i am sure it can be done in hal so that they move together, but still do not know why ....

Please Log in or Create an account to join the conversation.

More
22 May 2022 20:31 - 22 May 2022 20:35 #243575 by snowgoer540

OK, homing.c works with absolute values for home sequences but this statement is incorrect.

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.


Z homes, X homes, then Y the synchronised axis homes last.


What I wrote is absolutely correct, and how it works, and follows the both the 2.8.2 and 2.9 docs. Perhaps you are misremembering your setup, or you are not up to date.

Video to support (joint 3 is Z, joint 0 is X, and joints 1 and 2 make up tandem Y). Z homes, then X and Y home together, and they all wait to make the final move.
Warning: Spoiler!



From the docs:

Negative HOME_SEQUENCE values indicate that joints in the sequence should synchronize the final move to [JOINT_n]HOME by waiting until all joints in the sequence are ready. If any joint has a negative HOME_SEQUENCE value, then all joints with the same absolute value (positive or negative) of the HOME_SEQUENCE item value will synchronize the final move.

A negative HOME_SEQUENCE also applies to commands to home a single joint. If the HOME_SEQUENCE value is negative, all joints having the same absolute value of that HOME_SEQUENCE will be homed together with a synchronized final move. If the HOME_SEQUENCE value is zero or positive, a command to home the joint will home only the specified joint.


I am guessing pncconf uses -2 in the mistaken belief that it is required for the gantry to home last.
I do find this very confusing.


This is user configurable in pncconf, it will make the sequence whatever you enter (there is a scenario where it wont, but we wont got there now). Save for if it's a tandem axis, it will add a negative sign in front of the sequence number.
Last edit: 22 May 2022 20:35 by snowgoer540.

Please Log in or Create an account to join the conversation.

More
25 May 2022 00:55 - 25 May 2022 01:54 #243738 by dannym
Ok, testing found a prob- if you use the mpg jogwheel and press the axis go-home button that calls G0 Y0, it throws a following error.  It was pretty easy to hit this prob.

Now if it's already running gcode, the jogwheel is locked out and there's no error.  But if you're turning the jogwheel and press anything that calls a gcode command or actually start a gcode file then you always get the following error


2.7 didn't have any prob.  Apparently 2.8 has a prob with jogging and  an interpreter command at the same time.  Granted, not much reason to hit a gcode command while moving, but for "go to axis home" it's not too unusual and Following Error is a REALLY ungraceful response.

My mpg hal does have a low pass filter so the motion is not jerky.  That does mean it will have some pending movement for a moment after stopping the wheel, so gating off the mpg jog counts when executing a command won't fix it.

Any ideas?
Last edit: 25 May 2022 01:54 by dannym.

Please Log in or Create an account to join the conversation.

More
25 May 2022 06:39 #243761 by dannym
Also, gotta note- I discovered the hard way that the gantry can get past one of the X-limit switches if you jog it all the way to the stop.

Never noticed in 2.7 because you can move the gantry before homing.  2.8 not being able to do that made the machine unrecoverable.  The homing cycle won't work because it went past the switch and will "home" forever by driving into the stops looking for the switch in the wrong direction.  It needs to back off a small amount to trigger the homing switch before it can do the homing cycle, but you can't move it with 2.8.  

There IS  reason to do coordinated gantry motion prior to homing, it turns out.

Please Log in or Create an account to join the conversation.

More
25 May 2022 09:04 #243767 by rodw
note that 2.8 and on expect that the home switch stays triggered all the way to the limit of travel. That way it knows from the home switch state at the start of homing which way it needs to move. Get it wrong and its not pretty!

Please Log in or Create an account to join the conversation.

More
25 May 2022 14:00 #243796 by dannym
Yeah if I move the switch closer to the endstop, the jog speed may need to be lower to stop it in time.

I didn't even notice before that there was a dead space between the switch and the endstop where the switch could be off. I became aware of it real quick sitting there looking at the predicament. I can't home and since jogging is now disabled until you home I can't jog back the half an inch needed to resolve the problem. I wasn't planning to finalize converting to 2.8 yet so I plugged the cables back into the 2.7 box and jogged off with that installation.

Any thoughts on the Following Error if the jogwheel is still active when you hit a button that invokes a g-code command? That's a red flag blocking the conversion.

Please Log in or Create an account to join the conversation.

Time to create page: 0.088 seconds
Powered by Kunena Forum