Gantrykins Questions

I've got a moving gantry machine that's been working using trivkins. I'm adding a Mesa 5i25 for step generation, and was advised to switch to gantrykins. I've converted the INI and HAL files, and am able to jog each motor independently. I have two questions, however:

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

Ok, I had an idea. I'm trying to home the gantry by using "MACHINE->HOMING->HOME Y". I assumed this means to home the Y axis, which consists of 2 joints. Is it possible this is another example of the confusion between joints and axes in EMC2, and the command really means to home the second joint? If so, is there any way to home the gantry without homing all the joints?

Tom

Tom , another way to reverse the reverse the stepper is to reverse the stepper motor connections , that then keeps the input side correct , but as Andy suggests , just invert the stepgen scale ,

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

So I think I've figured things out.

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

I've also built my self a gantry with XXYZ and now i'm using this with triv kins and netting together the 2 X.
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.

andypugh wrote:

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.

it would mean "home Y" in world mode, but I seem to recall that you can't home non-trivial kins in world mode.

That's the catch. You can't home in world mode because each motor has to respond independently to it's own homing switch.

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.

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.

It's a shame that the developers left this confusion when they introduced non-trivial kinematics.

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.
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

I've made progress, but still have something strange going on. To recap, I've got a moving gantry router and have added a Mesa 5i25 for hardware step generation. To do so, I've had to switch to gantrykins from trivkins.

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

I don't have a Mesa card, so i can't help with that, but have you tried to increase or decrease your acceleration? usually faster acceleration give less errors (in my experience..but i don't know why.) just to try if something changes..

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?