Pnncof Tandem Y axis problem

Hi Guys,

I have used Pnncof to set up a tandem Y axis on my Gantry plasma machine,

I cannot get the Y axises to jog together using the keypad in Axis GUI,

I can manually select the axis in the GUI and jog it using the jog buttons but cannot get the two motors to move together, only one motor jogs.

I have attached my INI and HAL files.

Any ideas as to what is going on?

Have you homed the system? LinuxCNC will be in joint mode before homing is complete

How do I home a duel Y axis individually?

If I can only jog one motor at a time I cannot get the gantry to the home position,

I dont have my motors connected to the gearboxes at the moment but I cannot work out how it will work when I cannot jog them together.

I guess the basic answer is that you are not expected to home by jogging but by
telling LinuxCNC to home and then linuxCNC runs a built in homing state machine.
(which it does in joint mode, switching to axis mode when homing is complete)

linuxcnc.org/docs/2.8/html/config/ini-homing.html

If you dont have at least simulated limit switches yet you will have to disable homing by
setting up "immediate homing" ( in section 3.13 )

For gantry homing setup check out the homing sequence section (3.10)

Thanks PCW,

My INI file did not have the following so I had to add lines to each joint,

HOME equals to HOME_OFFSET

HOME_SEQUENCE = 0 (or other valid sequence number)

After I homes each axis the motor will jog as they should,

Does anyone know how CommandCNC is on start up able to jog the gantry without homing first?

thefabricator03 wrote: HOME_SEQUENCE = 0 (or other valid sequence number)

Which LinuxCNC version are you using?
I would strongly recommend using version 2.8 and then the tandem joints should have the same _negative_ home sequence number.

Does anyone know how CommandCNC is on start up able to jog the gantry without homing first?

LinuxCNC can be configured that way, for example by running both motors from the same joint position signal.
But independent joints and home switches is a better solution.

Make sure that you are reading the correct documentation for the version you are using, homing, especially, has changed in important ways between 2.7 and 2.8.

I am using 2.9.0~pre0 version of the Plasmac branch.

Why was HOME_SEQUENCE not generated in the INI file from PNCCOF?

Life will become easy if you just accept that you must hit home all before doing anything with your machine.

BUT:

I'm not seeing a
HOME_SEQUENCE in your joints in the ini file

add this to your ini for each joint
Joint 0 - HOME_SEQUENCE = 1
Joint 1 - HOME_SEQUENCE = -1
Joint 2 - HOME_SEQUENCE = -1
Joint 3 - HOME_SEQUENCE = 0

Make sure you have some home switches, hit home all and watch the magic happen!
The Z axis will home (it is homed at the top right?) to clear any stuff on the gantry, then The X axis will home, then the Y axis will home in unison. The Y axis homing is a race to the finish. The first one to home base stops and waits politely for the other side to catch up and then they home in unison finally squaring based on the HOME_OFFSET . Very cool to watch if done slowly with a racked gantry...

See
linuxcnc.org/docs/devel/html/config/ini-homing.html
and
linuxcnc.org/docs/devel/html/config/ini-...t__lt_num_gt_section

thefabricator03 wrote: Why was HOME_SEQUENCE not generated in the INI file from PNCCOF?

github.com/LinuxCNC/linuxcnc/blob/3b009f...nf/build_INI.py#L435

It looks like pncconf will create HOME_SEQUENCE entries if every joint has a home switch input defined.
Unless something is wrong. Did you define home switch inputs?

I never actually thought about this when I first built my gantry and used V 2.8 just after Joint Axes was pushed to it as I was that paranoid about limit and homing switches.

But when I think about it, unless I'm off the mark, you can't have a gantry without working homing switches.

V 2.8 knows about joint axes and refuses to jog them until they are homed. Really provided they are moved together, there is nothing stopping them from being homed. Perhaps V 2.9 might surprise us and allow joint movement before homing. But this implies that the gantry can't be considered to be square which is pribably why V 2.8 insists home all is completed before allowing jogging.