Custom gantry, loses steps

palmerr

Hi,I've been working on the following for a while and can't seem to beat it.My setup: Arduino Mega 2650, RAMPS 1.4 driving a hot end on my CNC router with big, slow steppers. For X, Y, Z I take Step and Dir straight from the RAMPS pins (no A4988 stepper driver) to the CNC gantry driver electronics (TBA 6560 drivers).The Y axis regularly loses steps. Not at the stepper driver, but the pulses simply aren't issued by the Arduino. I've confirmed this by both CRO and logic analyser - all the way back to pin A6 on the Arduino board.For example, if I home the printer and then issue: G0 F9000 X87.677 Y91.266 Z0.300Then what will often happen is that the printer will head off on a nice diagonal and then, midway, the Y axis will stop moving while X continues.Another example: Using Manual Control, if I continually step Y10, randomly the carriage will stop moving mid travel. The carriage doesn't decelerate as it normally would, steps simply stop being issued by the firmware.My suspicion is that settings I'm using for my slow steppers have such long delays in them that it "confuses" the firmware or causes some kind of buffer overrun.I completely remade my firmware this week with a fresh copy of 0.92I hope you can help
I can't see a way to attach my Configure.h file, so the key config settings are:#define DELTASEGMENTS_PER_PRINTLINE 24#define STEPPER_INACTIVE_TIME 360L#define MAX_INACTIVE_TIME 360L#define MAX_FEEDRATE_X 30#define MAX_FEEDRATE_Y 30#define MAX_FEEDRATE_Z 20#define ENABLE_BACKLASH_COMPENSATION 0 #define RAMP_ACCELERATION 1 #define STEPPER_HIGH_DELAY 20 #define DIRECTION_DELAY 20 #define STEP_DOUBLER_FREQUENCY 10000#define ALLOW_QUADSTEPPING 1#define DOUBLE_STEP_DELAY 1000 // time in microseconds#define MAX_HALFSTEP_INTERVAL 1999#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_X 50#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Y 50#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Z 30#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_X 75#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Y 80#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Z 50#define MAX_JERK 4#define MAX_ZJERK 0.3#define PRINTLINE_CACHE_SIZE 16#define MOVE_CACHE_LOW 10#define LOW_TICKS_PER_MOVE 250000#define FEATURE_TWO_XSTEPPER 0

Repetier

Maybe a speed problem. You have DOUBLE_STEP_DELAY 1000 so with double stepping your max. frequency is 1000. So you have to hope that you never reach that,

#define STEPPER_HIGH_DELAY 20 is also long but I know some toshiba drivers are slow, so i assume you really need them. So you should make sure speed is not higher then 10KHz or computations would result in impossible timings and I can not say what the result would be. I hope that is the reason, knowing that it normally works perfectly.

palmerr

Thanks.With STEPPER_HIGH_DELAY, the min clock is 10uS on my drivers. I'll reduce it to the minimum to reduce the wait loops.With the slow travel speeds, the max pulse rate is only 2500Hz.I only recently added the double step delay, so I'll try something much shorter.Not sure what you mean by the 10kHz speed comment, but I'll RTFM and the code and nut it out.I'll go back and explore those settings in more detail.When I've nutted it out I'll add a Tips and Tricks article, as others using larger slower machines must have similar problems with tuning the settings.Thanks again.

palmerr

I've spent a couple more hours trying your suggestions. No joy.Reliably, if I execute: G0 F1800 X90 Y80part way (differs exactly where) Y pulses simply stop and don't resume, i.e. the movement changes from a diagonal to a straight X traverse.Also issuing Y +/10 on Manual Control randomly exhibits the same issue.I don't think I'm hitting the double step limit, however I did reduce DOUBLE_STEP_DELAY to 15 to see if I was causing trouble with calling a long delay in the double step routine (no improvement).Any further thoughts?Revised config:#define DELTASEGMENTS_PER_PRINTLINE 24
#define STEPPER_INACTIVE_TIME 180L
#define MAX_INACTIVE_TIME 360L
#define MAX_FEEDRATE_X 30
#define MAX_FEEDRATE_Y 30
#define MAX_FEEDRATE_Z 20
#define HOMING_FEEDRATE_X 12
#define HOMING_FEEDRATE_Y 12
#define HOMING_FEEDRATE_Z 3
#define RAMP_ACCELERATION 1
#define STEPPER_HIGH_DELAY 15
#define DIRECTION_DELAY 15
#define STEP_DOUBLER_FREQUENCY 10000
#define ALLOW_QUADSTEPPING 1
#define DOUBLE_STEP_DELAY 15 // time in microseconds
#define MAX_HALFSTEP_INTERVAL 1999
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_X 50
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Y 50
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Z 30
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_X 75
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Y 80
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Z 50
#define MAX_JERK 4
#define MAX_ZJERK 0.3
#define PRINTLINE_CACHE_SIZE 16
#define MOVE_CACHE_LOW 10
#define LOW_TICKS_PER_MOVE 250000
#define ENABLE_QUADRATIC_ADVANCE 0

palmerr

EUREKA!It was that old bugbear, crosstalk with the (optical) endstop signals randomly triggering "I have hit a travel limit" - which, of course stopped travel on that axis. It just happened to be Y that had the greatest sensitivity to the issue.Thanks for your assistance the other day.Richard