weird homing problem after stepper driver update

More
13 Mar 2018 23:00 #107313 by johnbump
I've been lurking here for years and running emc2/linuxcnc since 2002-ish, and just ran into something I've not seen and don't quite know how to diagnose.
I have a Sherline mill with three home switches wired in series to an all_home signal on the parallel port. This worked fine with my linistepper driver, which I stopped using because they ran so hot, and worked fine with the THB6064 stepper motor drivers I replaced them with. I recently upgraded to Gecko 250's because the 6064's audibly squealed and I blew one up, and the 250's are said to be basically perfect, and they are: once the machine is homed, they run fast, strong, and smoothly, down to very low speeds.
The problem is when I start the homing routine: they drive the stepper motors in a very intermittent, sporadic fashion, like one of the leads isn't hooked up or something. Little beeps and burps of motion with big chunks of no movement in between. The system does correctly determine that the limit switches have been hit, then goes right back to jumpy intermittent movement until the switches are released, and at that point the axis in question moves smoothly away and works perfectly from then on.
I'm using release 2.6.1 on the same computer I used with the lini's and the 6064's.
The search_vel and latch_vel speeds are well within the range at which the geckos smoothly drive the axes once the machine is homed and running. It's like the system is using a different max step rate for the homing movements than it's using for normal movements: is that possible?
Any ideas anyone has would be quite welcome. I haven't found any hits from websearches on this, yet.

Please Log in or Create an account to join the conversation.

More
14 Mar 2018 20:59 #107358 by andypugh
That is completely bizarre.

Just as an experiment, try reducing the home and latch velocities by a factor of 10. That way you can be sure that you are looking at the right numbers, and it will be clear that it isn't speed related.

Please Log in or Create an account to join the conversation.

More
03 May 2018 04:06 #110084 by johnbump
I've been playing with this quite a bit since I last posted, and still haven't managed to fix or even further diagnose the problem.
Still in the same situation: my ini has max velocity 0.2, default velocity 0.1, and I currently have one axis home and latch velocities set to 0.0001, and another axis home and latch velocities set to 1000000(one million, in case you don't want to count all the zeroes) and neither works at all, nor does the third axis, set at about 1 for each. The one set to 0.0001 does move a little more slowly when it does move, than the other two, but the other two appear to be moving at about the same speed, just little tiny blips of movement (in the correct direction, at least) with hundreds of milliseconds to seconds of time in between movement.
Again, as soon as I (by hand, by pushing the limit switches) tell it that each axis has homed, from then on the machine works beautifully. I set it up to move 1.000 inches back and forth with a DTI on it, and did it about a thousand times, which showed the expected 0.008" backlash and zero accumulated error.

[EMC]
MACHINE = gecko_V6_experimental
DEBUG = 0

[DISPLAY]
DISPLAY = axis
EDITOR = gedit
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
ARCDIVISION = 64
GRIDS = 10mm 20mm 50mm 100mm 1in 2in 5in 10in
MAX_FEED_OVERRIDE = 1.2
MIN_SPINDLE_OVERRIDE = 0.5
MAX_SPINDLE_OVERRIDE = 1.2
DEFAULT_LINEAR_VELOCITY = 0.10
MIN_LINEAR_VELOCITY = 0
MAX_LINEAR_VELOCITY = 0.20
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/john/linuxcnc/nc_files
INCREMENTS = .1in .05in .01in .005in .001in .0005in .0001in

[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 = gecko_V6_experimental.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 0.10
MAX_VELOCITY = 0.20

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

[AXIS_0]
TYPE = LINEAR
HOME = 9.0
MAX_VELOCITY = 0.2
MAX_ACCELERATION = 0.8
STEPGEN_MAXACCEL = 1.0
SCALE = 40000.0
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = 0.0
MAX_LIMIT = 9.01
HOME_OFFSET = 9.000000
HOME_SEARCH_VEL = -1000000.0000
HOME_LATCH_VEL = 1000000.00
HOME_SEQUENCE = 1

[AXIS_1]
TYPE = LINEAR
HOME = 4.75
MAX_VELOCITY = 0.2
MAX_ACCELERATION = 0.8
STEPGEN_MAXACCEL = 1.0
SCALE = 40000.0
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = 0.0
MAX_LIMIT = 4.76
HOME_OFFSET = 4.750000
HOME_SEARCH_VEL = -1.00000
HOME_LATCH_VEL = 1.00
HOME_SEQUENCE = 2

[AXIS_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 0.2
MAX_ACCELERATION = 0.8
STEPGEN_MAXACCEL = 1.0
SCALE = 40000.0
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -9.0
MAX_LIMIT = 0.01
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -0.0001
HOME_LATCH_VEL = 0.0001
HOME_SEQUENCE = 0

Please Log in or Create an account to join the conversation.

More
03 May 2018 09:47 #110102 by andypugh
It will home the Z first. With the settings you have you would expect to see 4 steps per second on that axis during homing.

I think that the problem must be in the HAL, not the INI.

Is there anything connected to an "is homed" pin in the HAL that might explain this?

Check that the HAL is reading the INI values for accel and velocity, rather than being hard-coded.

Please Log in or Create an account to join the conversation.

Time to create page: 0.126 seconds
Powered by Kunena Forum