I have an uno running estlcam control + cnc shield x2 controlling 5 steppers from 5 separate drivers at 20V, X and Y are 1/8th step and the z in 1/4 step. The issue is when I flip the power switch that enables the power to the shields, all of the motors go bang bump thump. I have watched the motors and they all seem to “jump” to the closest full step causing the machine to force itself out of alignment. This also generates a usb sending error in estlcam, forcing me to close out of my project I had open and pull the usb cord from the Arduino and plug it back in then start estlcam again.
Any ideas how I can make it a “soft start”?
Also looking for ideas on getting back to square after the motor jump? (I have been forcing one side or the other to skip steps to get close to square)
Can one use duel end stops through Mega grbl? (grbl on an Arduino mega)
Thanks for any and all help
I don’t think the estlcam firmware can do auto squaring on dual endstops. The drivers can’t tell where the stepper motors are when they start, so they have to start on a full step. If you were using Marlin with a 5 driver board, you could use dual endstops and then when homing, the software can measure which microstep to stop each motor to keep it square.
The only alternative I can think of is to try to adjust the belts to get a full step square.
To be fair, one full step is 1/200th of a rotation and there are 16T pulleys, 2mm pitch belt. So a full step is 0.16mm. That is pretty close, for squareness.
The other issue, related to a usb reset, is that really caused by the motors?
No the estlcam does not support duel end stops, but I am wondering if GRBL for the Mega would support duel end stops, I haven’t looked into it much yet.
That all makes sense I have been living with the issues for years, I used to never turn it off to keep square but my motors would reach 45C, I then would begin losing torque and ultimately losing micro steps, in turn I installed heat syncs and fans to bring the temps down and bring the torque back up.
I don’t think it is exactly caused by the motors, more like the motors are a visual and audible component during the issue.
I’m pretty sure the usb problem is related to the influx of current when all of the drivers get energized at the same time, possibly its the fly back voltage from the motors searching for ground and finding it through the usb connection. I have read somewhere that if I was to cut the ground pole off of the plug for my computer’s power supply it could help but I haven’t tried that. It used to happen when I would pull the plug or insert the plug out of or into the electronics enclosure DC side. (my last setup before I installed a large toggle switch to turn it off)
Now with the large toggle switch it will only trip the usb sending error when turning it on.
An interesting note is that I am using a dell laptop charger for my power supply, and if I unplug the AC side of the power supply it will only periodically set off the usb sending error. Where as switching the DC side of the supply will cause a usb sending error every time.
Hackish idea that may not work. Maybe if you leave the electronics on but issue a M18 when you are not cutting to disable the steppers you could get around the overheat and USB sending error.
Apparently M18 is a Marlin g-code command and does not work in GRBL. A quick search yielded that $1 can be used in GRBL to disable the steppers. Quoting:
$1=255(step idle delay, msec) – This is the delay in milliseconds after a move instruction before the stepper motors are disabled. Setting this to 255 keeps motors always enabled.
So setting the value to something other than 255 should result in the motors shutting down.