fra589 / grbl-Mega-5X

5/6 Axis version of Grbl, the open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on an Arduino Mega2560
https://github.com/fra589/grbl-Mega-5X/wiki
Other
346 stars 161 forks source link

Acceleration is ignored with cloned axis #340

Open gpstone opened 1 year ago

gpstone commented 1 year ago

Discussed in https://github.com/fra589/grbl-Mega-5X/discussions/308

Originally posted by **gpstone** November 18, 2022 Hello. I am stuck and need some help on a strange issue where GRBL is ignoring axis acceleration value only on certain sequential G0/G1 commands. When this happens at full speed/acceleration, the stepper motors physically skip steps (usually just on one axis) and in severe cases the machine jams if one of the cloned axis skips and the other tries to continue. The problem started after upgrading my machine to GRBL Mega from GRBL 1.1f (Uno). I have a gantry CNC with dual X axis motors and limit switches for gantry squaring. Originally I thought the problem was due to acceleration or axis speed being set too high. However, I was able to rule this out by slowing down the acceleration to an extremely slow speed (i.e. 5mm/s^2) and with things slowed down I could clearly see and hear the missed deceleration/acceleration curves on the G0 commands. The steppers made a 'hard' stop/start 'clunk' instead of a gradual decel/accel. I have ruled out hardware issues by disabling axis cloning in config.h and physically wiring both X axis controllers to the same step/dir pins. When I do this, the problem goes away (Although I lose self-squaring). Also, what points me to a config or software issue is even when I physically have the axis wired to the same X outputs but then re-enable cloning of the X axis in config.h (nothing is physically connected to those pins), the issue with missed acceleration comes back. Everything else seems to be setup and working fine. Homing works for all 4 axis. Everything is moving in the right direction. I can run Gcode programs (Except for occasional skipped steps due to this issue). What's very frustrating is the issue only happens on certain types of G commands. It is very repeatable with the same command, but some other combinations will work just fine. Example gcode where acceleration is ignored G21G0X25Y25 //Misses decel/accel between this line and next G21G0X755Y25 G21G0X-153.968Y93.316 G21G0X-124.362Y40.107 //Misses decel/accel between this line and next G21G0X-41.833Y-17.287 Troubleshooting I have tried: - $RST=* command (several times) - Various $ machine settings: Step pulse timing, Arc tolerance, Junction deviation, verified all the Accel and step setting match for cloned axis, etc. - Various config.h settings: moving the cloned 'X' axis to AXIS 4/5/6, trying different homing cycles, etc - Downloading and using the latest edge build of Mega-5X. (Note: This issue was also happening with prior build when I first upgraded to Mega around March 2022, so it's not an edge issue) - Full EEPROM wipe of Mega controller - Replacing/Upgrading from a generic mega board to a genuine Arduino Mega - Downloading latest build of UGS Sender Any ideas on what I can try next would be greatly appreciated. Thank you in advance! >>> $I [VER:1.2g.20220917:] [AXS:4:XYZ] [OPT:VNMGH,35,255,48] >>> $$ $0 = 10 (Step pulse time, microseconds) $1 = 255 (Step idle delay, milliseconds) $2 = 0 (Step pulse invert, mask) $3 = 0 (Step direction invert, mask) $4 = 0 (Invert step enable pin, boolean) $5 = 0 (Invert limit pins, boolean) $6 = 0 (Invert probe pin, boolean) $10 = 1 (Status report options, mask) $11 = 0.010 (Junction deviation, millimeters) $12 = 0.002 (Arc tolerance, millimeters) $13 = 0 (Report in inches, boolean) $20 = 1 (Soft limits enable, boolean) $21 = 0 (Hard limits enable, boolean) $22 = 1 (Homing cycle enable, boolean) $23 = 11 (Homing direction invert, mask) $24 = 25.000 (Homing locate feed rate, mm/min) $25 = 4000.000 (Homing search seek rate, mm/min) $26 = 250 (Homing switch debounce delay, milliseconds) $27 = 2.000 (Homing switch pull-off distance, millimeters) $30 = 24000 (Maximum spindle speed, RPM) $31 = 7200 (Minimum spindle speed, RPM) $32 = 0 (Laser-mode enable, boolean) $100 = 80.120 (X-axis travel resolution, step/mm) $101 = 80.120 (Y-axis travel resolution, step/mm) $102 = 161.900 (Z-axis travel resolution, step/mm) $103 = 80.120 $110 = 6000.000 (X-axis maximum rate, mm/min) $111 = 6000.000 (Y-axis maximum rate, mm/min) $112 = 3000.000 (Z-axis maximum rate, mm/min) $113 = 6000.000 $120 = 5.000 (X-axis acceleration, mm/sec^2) $121 = 5.000 (Y-axis acceleration, mm/sec^2) $122 = 5.000 (Z-axis acceleration, mm/sec^2) $123 = 5.000 $130 = 790.000 (X-axis maximum travel, millimeters) $131 = 648.000 (Y-axis maximum travel, millimeters) $132 = 200.000 (Z-axis maximum travel, millimeters) $133 = 790.000 Config file: [Config.txt](https://github.com/fra589/grbl-Mega-5X/files/10046007/Config.txt)
fra589 commented 1 year ago

Hi @gpstone,

You are right, I'm convinced it's a bug, probably located in the code of planner.c or stepper.c... But difficult to find in this particular complex code portion.
I haven't found the fix yet. I had very little time this year to do maintenance on grbl-Merga-5X (and others software). I hope to find this time after the summer (I will be in traveling until mid-September, so I will not be able to fully do it before).

Thanks for your patience.

@++; Gauthier.

simrim1 commented 1 year ago

Hi fra589, I am also facing the same issue. Built my own CNC router. Installed all electronics with 17hs19-2004s1 steppers with 2A/phase ,DRV8825 drivers with 1/8 microstepping, PC ATX power supply with 12V and loads of Amps and Arduino Mega with Ramps 1.4 shield.

It started intermittently and it became more frequent. I was not convinced that it was because of NEMA 17 motors. I am using two on X axis and 2 on Y Axis. So I am sure they got enough torque and power to move gantry easily. The gantry movement is butter smooth if i rotate motors' couplings with my hand.

I spent almost 2 days to figure out what was going wrong with different parameters. From Low to High with the same results. I even detached the lead screws and ran motors without any load and they were stalling. I got very confused. Checked everything multiple times but couldn't figure out the problem.

I am new to CNC world so I was convincing myself that I was doing something wrong and looking for help online I came across this thread.

I hope this will be fixed soon.

@gpstone you found any workaround? How are you running your machine now?

gpstone commented 1 year ago

Hi @simrim1 Currently my workaround is to configure GRBL as 3 axis with no cloned axis. Then I physically wired the step and direction input to both my X1 and X2 stepper controllers to the same X output pin of the GRBL controller. The downside to this is that the self squaring function does not work, so I have to manually square the gantry. The X homing is done only with the switch connected to X1. Basically my X2 motor is just along for the ride.

simrim1 commented 1 year ago

Hi @gpstone Thanks for the update on your workaround. It seems like original GRBL for Arduino Uno. Isn't it? I found and old Arduino UNO in my closet along with it CNC shield. Removed the dirt, flashed fresh GRBL and used Cloned Y-axis built-in the CNC shield. Alas I also lost Self-Squaring but my CNC is running without any problems now. No missing steps, motor stalls and/or grinding noise of lead screws on acceleration/deceleration.

I am hopeful this bug in Mega-5X will be removed soon and I will be back to Mega. Thanks again for the update.

fra589 commented 1 year ago

Hi all,

This reminds me that I'm way behind on the grbl-Mega-5X work...

The workaround consisting of configuring without using cloning and connecting the stepper motor drivers to be cloned to the same output works on grbl-Mega-5X, there is no need to go back to an old Arduino Uno board.

@++; Gauthier.

pgordinho commented 5 months ago

I'm convinced I have this problem too. Hard to explain, but I have a video. Cloned X won't move and X does some strange movements when decelerating. Does anyone knows when was this problem introduced? I was using a previous version that didn't have this problem. It only came after I upgraded the firmware on the controller.

fra589 commented 5 months ago

Hi @pgordinho,

Oh, that’s an interesting comment! Can you tell which previous version worked well?

@++; Gauthier.

pgordinho commented 5 months ago

Hi @fra589 ,

I can. It worked well with this version I found while building my MPCNC. https://drive.google.com/file/d/1yO2Ap2ItG70cV79RdZLC40aMKHEdPUZl/view?usp=drive_open

So I installed again this version, did a $RST=, configured everything again and it worked without a problem. Beeing stubborn, I againd installed the new version from here (1.2h), change a few settings in cpu_map.h to match my end stops and again a $RST=. After I reconfigured the settings and now this version is working well also. So, I really don't understand what append in the first place.

I have a feeling that my problem was not something in the code itself, but in the cpu_map.h settings. Maybe a misconfigured pin or someting like that. but the symptoms where just like the ones from the OP. Mostly everything works fine, with the exception of some codes that move only the X axis and not the X cloned one.

I'm sorry I can't help much help and thank for the excellent work with this build.