Trouble with dual motor gantry setup

This is a new install on a cnc with dual motors on a gantry on X, and single on Y and Z.
I have followed forum.linuxcnc.org/49-basic-configuratio...s-on-one-axis-gantry
to try to setup a gantry system with dual motors on the X, but cannot get the jogging to work as expected.

Am running the silverdragon frontend and when I try to jog X one motor jogs. When I try to jog Y the other X motor jogs. Z jogs Y and cannot jog Z at all. It seems straight forward that it is getting out of sync, but cannot see what I should change.

If I change to gmoccapy I changes so that the XY and Z jog Ok, but the second X doesn't.
Do I have to do something in the frontend setup to hook this up.

I have confirmed with the stepconf wizard that all steppers work on the pins indicated.

Don't know if it is relevant, but when I try to jog the Z and Y motor moves the display show the Y-Axis moving

BTW very new to linuxcnc (not an excuse, just a mitigating factor)

That is an old thread and a lot has happened.
Refer to the real docs..
linuxcnc.org/docs/2.8/html/config/ini-homing.html

Assuming you have V 2.8 or higher, you need to change the HOME_SEQUENCE for your two joint X axes to be -1. This tells the system to treat them as one.

If < 2.8 you need to upgrade.

Thanks for that, have 2.8. will try it tomorrow.

Hi Peter,
take a look at chapter 6.10. HOME_SEQUENCE on.
linuxcnc.org/docs/2.8/html/config/ini-homing.html
Your home sequence doesn't seem right. Gantry axes have one - in front of it. That is probably the reason why your 2 X-axis does not move. It is not homed.
If you want all homing with one button, the sequence is also set.
HOME_SEQUENCE = 1 # first axis mostly Z;
HOME_SEQUENCE = 2 # X or Y.... and so on

In the case of a gantry axis, write -1 or -2 in both axes.

chris@cnc wrote:

Hi Peter,
take a look at chapter 6.10. HOME_SEQUENCE on.
linuxcnc.org/docs/2.8/html/config/ini-homing.html
Your home sequence doesn't seem right. Gantry axes have one - in front of it. That is probably the reason why your 2 X-axis does not move. It is not homed.
If you want all homing with one button, the sequence is also set.
HOME_SEQUENCE = 1 # first axis mostly Z;
HOME_SEQUENCE = 2 # X or Y.... and so on

In the case of a gantry axis, write -1 or -2 in both axes.

HOME_SEQUENCE = 1 # first axis mostly Z; should be HOME_SEQUENCE = 0 # first axis mostly Z;

Thanks for the help, the led me in the right direction.

Funnily enough I was leaving the limit switches until I was sure that I had all the motor setup and direction sorted. This is a bit of a beast of a machine so I am a little bit tentative on doing things like pressing the home all

After trying to setup the limits I realised that we only have a single sensor on the X with the dual drives so treating it as a XXYZ probably has no benefit (the 2nd sensor got destroyed in a previous life). I have now set it up as recommended in forum.linuxcnc.org/38-general-linuxcnc-q...-on-one-joint#142088 and I seem to have more success.

I am sure this won't be the last question, but thanks for the help.
I have currently switched to gmoccapy mainly for the ability to override limits. If you go past limits on this machine it is hard to get it back (the gantry does not easily freewheel and weighs a ton)

I did not see a config specifically for what I am doing as this has a single sensor on each axis that is always on when inside limits, but was able to work it out

Thanks for the help. I will upload the current config and get a better desc of what is currently happening.

Currently the homing just errors out when hitting the limit switch.

I will post a desc of the machine in a few hours.

here is a link to some photos photos.app.goo.gl/HMw2qjZ6G6dreh567
You can see that there is an inductive sensor on the gantry that is activated when the gantry is in the normal range of the axis. Holes drilled at each end mean that the sensor is deactivated when it approaches. This is typical for all axis.

In a few photos you can see the physical endstops welded into the rail mountings. Things get a bit serious if you run into those.

The Silverdragon UI does not have the limit override, which is why I used the gmoccapy. This machine is part of a shared makerspace and part of this is to improved the usability for users. I will be looking at other interfaces as well.

Part of this challenge is that the UI gives a good indication of the state of the machine. Previously had mach3 which could be perplexing to say the least. Also have the chinese huan yang vfd which does not seem to work with mach4. Am also happy to modify any interface to help improve it for our specific case. We have quite a few programmers, myself included.

Quick feedback from the forums here indicates the reason we are looking to change, I already have linuxCnc installed on my desktop taig mill at home. I have setup dual microswitches on each axis on mine and the homing appears to do as expected. Will be doing some tests tonight.

So its good you are having more luck now.
I would be a little bit concerned about your sensor triggers. (or un-triggers). Its easy to invert a signal in hal but Linuxcnc expects your home sensor to remain triggered all the way to limit of travel. It requires this to know which way to travel to clear the home sensor if the home switch is enabled at the start of homing. If you are near the max limit and you try homing, the result won't be pretty as it will find you hard stops very quickly ( I know about this fist hand!) Those holes really need to be slots.

You might like to have a look at the sensor triggers I devised for my spaceship plasma table as they would be easy to add to your table. You just need to raise the prox sensor to clear them which might be easier than cutting slots.
See the very first post for details here. forum.linuxcnc.org/show-your-stuff/32029...cutter-build?start=0

A machine that size really is crying out for more I/O than a parallel port offers. You could add a second par port, but the Mesa 7i76e would be ideal. If you live downunder in .AU like me and you want one in a hurry I might be able to help out. You'll find my number on my web site www.vmn.com.au/

And as Tommy said, a machine should never hit a hard limit because the limit switches are inside those limits and the home switch (if not shared) should always be inside the limit switches and remain triggered all the way to the limit switch. I know a lot of people only use a single home switch and rely on soft limits which is OK if you have limited IO. I chose to do it properly because I figured if they were supported, it was for a reason. I will say the hardest axis I set up was my Z axis which used a shared home/limit switch. For such an axis, you must use a home offset to move the home switch off the trigger otherwise your limit switch will fire once homing is completed. I just resented giving up travel to achieve this so would set my next machine up the same way as my Spaceship.