Linking two gantry joints with homing switches so it unracks on home
- tommylight
- Away
- Moderator
- Posts: 19206
- Thank you received: 6437
Nope, that will not work.What I mean, if you start with -2, then isn't the sequence -2,-1,0,1,2....
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.
- tommylight
- Away
- Moderator
- Posts: 19206
- Thank you received: 6437
[/quote]This is the confusion I see. -2 is illegal by my read.
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.
- snowgoer540
- Offline
- Moderator
- Posts: 2388
- Thank you received: 779
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.
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.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..
Please Log in or Create an account to join the conversation.
Z homes, X homes, then Y the synchronised axis homes last.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.
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]
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 19206
- Thank you received: 6437
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.
- snowgoer540
- Offline
- Moderator
- Posts: 2388
- Thank you received: 779
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.
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.
Please Log in or Create an account to join the conversation.
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?
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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.