Gantrykins Questions
- PortlandGTS
- Offline
- Junior Member
- Posts: 34
- Thank you received: 1
1. The two gantry motors must spin in opposite directions. Currently, I just invert the direction signal to one of the motors. However, when I go to hardware generation, I won't have access to the direction signals. How do I accomplish this?
2. Even though I can jog all the joints independently, when I try to home the gantry, only one motor spins. Any ideas as to what's causing this? Based on a previous thread, I made sure the INI parameters for the two gantry motors are identical.
Thanks,
Tom
Please Log in or Create an account to join the conversation.
- PortlandGTS
- Offline
- Junior Member
- Posts: 34
- Thank you received: 1
Tom
Please Log in or Create an account to join the conversation.
Gantrykins is only worth the trouble if you have limit switches for both sides of the gantry, otherwise it is rather more trouble than it is worth.was advised to switch to gantrykins. I've converted the INI and HAL files, and am able to jog each motor independently.
Set one of the stepgen scales negative.The two gantry motors must spin in opposite directions... How do I accomplish this?
I suspect that the homing sequence numbers for the two joints are not the same. Though you do say that the INI entries are identical.when I try to home the gantry, only one motor spins. Any ideas as to what's causing this?
Please Log in or Create an account to join the conversation.
treat each motor as a joint , rather than an axis , so the y axis is now 2 joints one we know as Y the other unknown ( as i dont have your files)
so your homing y ( joint 1) so you need to add joint2 into following ( joint 1 ) hence why when homing only one motor runs , so the option is to slave either the second y axis from the first , or supply both steppers with the same input signal .
joints are numbered from zero , starting x y z a b c u v w ,
post your hal and ini files and perhaps we can help ..
is their a reason your using gantrykins ? do you need to move both y steppers seperately
Please Log in or Create an account to join the conversation.
- PortlandGTS
- Offline
- Junior Member
- Posts: 34
- Thank you received: 1
The reason I need to use gantrykins is because I bought a Mesa 5i25 to provide hardware step generation. When using this, I won't have access to the output of stepgen within HAL. And driving the two motors from the same electrical signals prevents homing both sides of the gantry with their own homing switches. Besides, I've read that this is bad practice.
The guidance to make the scale parameter negative for one of the motors worked - now both motors spin in the same direction.
I also tried 'HOME ALL'. This worked fine. It confirmed what I suspected: "HOME Y" really means "Home joint 1", and "Home A" really means "Home joint 3". This is not only misleading, it's dangerous - If I hadn't disconnected the gantry motors before trying this out, I could have damaged my machine. As it is, I'll have to be very careful in the future.
This is the second time I've beeen tripped up by EMC2 using the term "axis" when "joint" should be used. See www.linuxcnc.org/index.php/english/compo...ew&catid=27&id=22600 . It's a shame that the developers left this confusion when they introduced non-trivial kinematics.
Thanks for all your help.
Tom
Please Log in or Create an account to join the conversation.
[quoteThe reason I need to use gantrykins is because I bought a Mesa 5i25 to provide hardware step generation. When using this, I won't have access to the output of stepgen within HAL. [/quote]True, though you can run two stepgens from the same motor-pos-cmd pin. (which is largely all that gantykins does in World mode.
it would mean "home Y" in world mode, but I seem to recall that you can't home non-trivial kins in world mode.also tried 'HOME ALL'. This worked fine. It confirmed what I suspected: "HOME Y" really means "Home joint 1", and "Home A" really means "Home joint 3". This is not only misleading, it's dangerous - If I hadn't disconnected the gantry motors before trying this out, I could have damaged my machine. As it is, I'll have to be very careful in the future.
You might be able to link axis.1.homing to halui.joint.3.home in HAL to force Joint 3 to home at the same time. Definitely something to test with the motors disconnected though.
It is, but the changes required go very deep. You might find that the joints-axes3 branch works better for you, which is where the work to sort this out is taking place.It's a shame that the developers left this confusion when they introduced non-trivial kinematics.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...s/heads/joints_axes3
You need to compile yourself from git to use it though.
Please Log in or Create an account to join the conversation.
Since I wanted to add separated homing switches, i was wandering if it could be better to use JointAxes3 branch (which i already use for non-triv-kins machines..)
So also i will try that, and report here if successful.
By the way, I think LinuxCNC 3 should be definitely based on JA3 concept.
Please Log in or Create an account to join the conversation.
- PortlandGTS
- Offline
- Junior Member
- Posts: 34
- Thank you received: 1
That's the catch. You can't home in world mode because each motor has to respond independently to it's own homing switch.andypugh wrote:
it would mean "home Y" in world mode, but I seem to recall that you can't home non-trivial kins in world mode.PortlandGTS wrote:
also tried 'HOME ALL'. This worked fine. It confirmed what I suspected: "HOME Y" really means "Home joint 1", and "Home A" really means "Home joint 3". This is not only misleading, it's dangerous - If I hadn't disconnected the gantry motors before trying this out, I could have damaged my machine. As it is, I'll have to be very careful in the future.
That's interesting. I failed to recognize that the homing signals are stil available in HAL, even though the step and direction signals aren't. I think I'll try this.You might be able to link axis.1.homing to halui.joint.3.home in HAL to force Joint 3 to home at the same time. Definitely something to test with the motors disconnected though.
It is, but the changes required go very deep. You might find that the joints-axes3 branch works better for you, which is where the work to sort this out is taking place.It's a shame that the developers left this confusion when they introduced non-trivial kinematics.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...s/heads/joints_axes3
You need to compile yourself from git to use it though.[/quote]
I didn't realize there was an effort to straighten this out. That's great, but I'm not sure I'm up to using a development version. I'll be interested to hear dab77's progress reports.
Tom
Please Log in or Create an account to join the conversation.
- PortlandGTS
- Offline
- Junior Member
- Posts: 34
- Thank you received: 1
I'm now able to home, jog, and actually run programs. Jogging, however,is behaving strangely.
At first, I was getting following errors. I found this thread which helped a lot:
www.linuxcnc.org/index.php/english/compo...=10&id=22514&limit=6
This greatly reduced the following errors, but they still show up when jogging at speeds above about 75 ipm. The errors show up when I release the jog button. The jogged axis quickly moves backward a little bit, as if it overshot where it was supposed to stop. I think this must be causing the following error. If I jog until I reach a limit, I will usually get a soft limit error, sometimes even a hard limit error.
I've found this happens only in world mode, not joint mode, and only when jogging, not when running programs.
Any ideas on what's wrong?
Thanks,
Tom
Please Log in or Create an account to join the conversation.
about the backward move i really can't imagine, since with steppers you don't have any feedback. so there should be either a bad programming or some wiring short circuit?
Please Log in or Create an account to join the conversation.