Auto-Squaring with LinuxCNC v 2.8

[Kitwn]

I suppose it was bound to happen. I wanted to change my X axis upper soft limit so I did what I've always done: ran Stepconf and changed it. Opened LinuxCNC and ran homing. Only one X axis motor started moving, the E-stop did nothing (that'll be something else to investigate ASAP) and the gantry alignment looked very sorry for itself by the time I turned off the motor PSU.

Once you set up a two motor axis as described above you MUST NOT run stepconf but make the relevant edits to the .hal and .ini files manually instead. I have saved versions of the .hal and .ini files for my machine so reloading was no problem. Fortunately there's no real damage done as the motor stalled before bending anything but the gantry-to-carriage bolts have clearly moved as the gantry will square itself when homed but visibly 'relaxes' when the motors are disabled with one side carriage moving a few millimetres along it's rail. An hour or so with a spanner and the big square required tomorrow morning.

I think I might create a new wallpaper for my LinuxCNC computer that has "DO NOT RUN STEPCONF!" written on it in big shiny letters. I can't be the only person to have suffered this lapse of concentration and if there's a way of easily disabling stepconf or preventing it from overwriting the relevant files I'd love to hear it.

Kit

PS As you may have realised my machine does not use fabulously rigid Hi-Win rails on its axes but has fully supported 20mm round rails with two linear bearings on each side screwed to a plate which the gantry then bolts to. There is about +- 3mm of easy movement between the carriages with the motors disabled. Once it's squared and the motors are energised everything is nice and stiff and the cutting is sufficiently accurate, but the auto-squaring is definitely a good improvement for a machine with so much slack on a two-motor axis.

[Clive S]

Once you set up a two motor axis as described above you MUST NOTl run stepconf but make the relevant edits to the .hal and .ini files manually instead.

Well as you now know stepconf is only to be used once and as is says at the top of the ini file it generates. It gives the warning not to not to rerun as it will overwrite any edits you have done.

But at least you had the foresight to make copies on the hal and ini files

I take it you know how to alter the homing squaring in software.

Keep up the good work its nice to see other Lcnc users on here.

[Kitwn]

Clive,
Well, yes it does say that but before this update I always used stepconf to make minor adjustments having never got my head round the inner workings. I was always careful to use the 'update existing file' option. Keeping safe copies of software before making changes is part of my DNA so it was only the mechanical effects I was worried about.

I'm sure I'm not the only user of LinuxCNC who is more interested in cutting wood than learning the intricacies of it's file editting, and I say that as someone with several years experience of designing and building assorted projects involving some quite complex Arduino code (never got as far as writing all of anything in C++ though).

Anyway we're all back to normal now with everything squared up again. Altering the homing squaring doesn't need alterations to the software, just a tweak of the microadjustable switch actuator shown here:

[Clive S]

Anyway we're all back to normal now with everything squared up again. Altering the homing squaring doesn't need alterations to the software, just a tweak of the microadjustable switch actuator shown here:

Yes that is one way. But is far simpler to just edit the ini file as you can get very fine adjustments. . (This is for the benefit of others to see that the config files are just plain text)


# Generated by stepconf 1.1 at Sun Jul 1 16:50:39 2018
# If you make changes to this file, they will be overwritten when you run stepconf again
# This file has been edited

[EMC]
MACHINE = test_for_slaved_axis
DEBUG = 0
VERSION = 1.0

[DISPLAY]
DISPLAY = axis
EDITOR = gedit
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
ARCDIVISION = 64
GRIDS = 10mm 20mm 50mm 100mm
MAX_FEED_OVERRIDE = 1.2
MAX_JOG_OVERRIDE = 1.2
MIN_SPINDLE_OVERRIDE = 0.5
MAX_SPINDLE_OVERRIDE = 1.2
DEFAULT_LINEAR_VELOCITY = 2.50
MIN_LINEAR_VELOCITY = 0
MAX_LINEAR_VELOCITY = 25.00
DEFAULT_ANGULAR_VELOCITY = 2.50
MIN_ANGULAR_VELOCITY = 0
MAX_ANGULAR_VELOCITY = 25.00
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/clive/linuxcnc/nc_files
INCREMENTS = .5mm .1mm .05mm .01mm .005mm
PYVCP = custompanel.xml


[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

[TASK]
TASK = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = linuxcnc.var

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 100000
SERVO_PERIOD = 1000000

[HAL]
HALFILE = wal_slaved_axis.hal
HALFILE = custom.hal
POSTGUI_HALFILE = postgui_call_list.hal

[TRAJ]
COORDINATES = XYZ
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_LINEAR_VELOCITY = 2.50
MAX_LINEAR_VELOCITY = 25.00

[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

[KINS]
KINEMATICS = trivkins coordinates=XXYZ kinstype=BOTH
JOINTS = 4

[AXIS_X]
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
MIN_LIMIT = -0.001
MAX_LIMIT = 200

[JOINT_0]
TYPE = LINEAR
# final home position machine-unit/sec
HOME = 70
MIN_LIMIT = -0.001
MAX_LIMIT = 200
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
STEPGEN_MAXACCEL = 937.5
SCALE = 320
FERROR = 1
MIN_FERROR = .25

HOME_OFFSET = 0.1 # use this to square the gantry

# machine-units per sec next 3 lines
HOME_SEARCH_VEL = 10 This is the speed it searches for the home switch use a -ve number to revervse
HOME_LATCH_VEL = -6 This the the speed it use to back off the switch use a -ve to reverse
HOME_FINAL_VEL = 20 This is the speed it will travel to the final HOME position

HOME_USE_IIDEX = NO

HOME_SEQUENCE = -1 # has to be -ve for gantry

[JOINT_1]
TYPE = LINEAR
# final home position machine-unit/sec
HOME = 70
MIN_LIMIT = -0.001
MAX_LIMIT = 200
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
STEPGEN_MAXACCEL = 937.5
SCALE = 320
FERROR = 1
MIN_FERROR = .25

HOME_OFFSET = 0.5 # use this to square the gantry

# machine-units per sec next 3 lines
HOME_SEARCH_VEL = 10
HOME_LATCH_VEL = -6
HOME_FINAL_VEL = 20

HOME_USE_IIDEX = NO

HOME_SEQUENCE = -1 # has to be -ve for gantry

[AXIS_Y]
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
MIN_LIMIT = -0.001
MAX_LIMIT = 200.0

[JOINT_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 25.0
STEPGEN_MAXACCEL = 937.5
SCALE = 80.0
FERROR = 1
MIN_FERROR = .25
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0
HOME_USE_IIDEX = NO
HOME_SEQUENCE = 0

[AXIS_Z]
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
MIN_LIMIT = -100.0
MAX_LIMIT = 0.001

[JOINT_3]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 25.0
STEPGEN_MAXACCEL = 937.5
SCALE = 80.0
FERROR = 1
MIN_FERROR = .25
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0
HOME_USE_IIDEX = NO
HOME_SEQUENCE = 0

[Kitwn]

Thanks Clive, I didn't know about that way of setting the squaring.
I have plans to make some new homing switches using latching Hall effect sensors and two magnets attached to the moving gantry. Using latching sensors will overcome the problems associated with the gantry overshooting the sensor while decelerating and might be more accurate/repeatable than conventional Hall sensors. That design may be less able to use the microadjustable switch actuator shown above so your method may well become necessary.

Kit

[michaelrommel]

Hi folks,
I am building such a gantry with two Y-axis motors/joints. I want to use these typical chinese proximity sensors as limit switches and homing switch.

In order to have the gantry square every time, the two sensors on the Y-Axes need to be precisely repeatable. So I wondered if any of you have experience whether it is better to approach the limit axially or radially (the cutout in the metal in the lower image shall act as an "open" of a NC sensor - with the axial approach this is not possible, of course.)

Where to those sensors detect more reliable?



Thanks for your insights!

Michael.

[Clive S]

Welcome to the forum Michael

I prefer the target going past the end of the sensor PNP NO as it is quite easy to break the sensor head on. PNP are easier to use with standard Mesa cards like 7i96 7i76 7i92 etc.

Of course as you probably know with linuxcnc 2.8 you adjust the home offsets to square the gantry in the ini file.