Dear hivemind, I've got a weird issue that I can't seem to locate. I've build a cnc mill based on the Minimill (linear rails, 2.2 kw spindle, epoxy filled,...) but when I run a program, whenever there seems to be a circular motion it starts acting weird. What does this mean? Well, I just ran a trace code with a marker for just a round circle and it produced this perfect half circle. It'll draw the first half, and then just strike through. Afterwards, my zero point is off a bit (in this pic I ran the code twice right after eachother). What I've checked: - removed hardstops - With spindle turned off (so no EMI from that) - With Z-axis stepper motor unplugged (so more than enough current for X and Y so I don't lose steps there) - Ran from an SD-card (to eliminate bad USB cable or bad gcode parser) - Different post (that replaces G2, G3 with incremental steps I believe) without any avail I also tried upping jogging speed and trying to induce any lost steps that way, which didn't work. Do any of you know if I just overlooked something? Added the program below as well. To any admins, I'm sorry if this is in the incorrect place. I didn't really know what to classify this under. If I need to move it, please send me a message and I will
looking at the gcode, it should start in the middle, move tool left, then cut the top of the circle going clockwise. The drawing in the picture indicates that the tool X and Y directions are incorrect. All axis directions as always 'tool motion', so with a moving table machine you have to be careful. X+ jog means the tool moves RIGHT, to do so the table moves left Y+ jog means the tool moves AWAY from you, and the table moves toward you. You have disabled hardwstops, does that means you also disabled homing? Home must be as + end of all axes, to table 'near' and 'left' (same as tool right and away), and Z UP. After homing you set part zero as a Work Coordinate System (WCS) zero in the middle of your workpiece, and your circle should cut around that 0,0 point
Hi David, Yes, you are correct. I had the Y directions wrong originally, that has been fixed. Yet the issue remains. I have disabled hardstops, and I don't home atm. I just zero WCS and start from there. Since this is a test, it does cut that one half of the circle around 0,0. (indicated by the dot on the first try, where I left the marker touching the paper a bit too long, the underside isn't visible because the paper isn't completely flat to the marker due to it being ductaped in the middle.) On the other hand, so far I got no reply from the controller designer, I also swapped X and Y drives and the issue still remains. So I'm pretty sure it's a controller issue. Thanks!
Consider a BlackBox https://docs.openbuilds.com/blackbox as a more known working config with our support team on standby
if you don't home, home is probably where you turned on and that means it won't cut in Y+ space. can you jog to all corners of the bed?
Hi David, Yes I can. Probably due to hardstops being disabled. There's no movement issue to reach all over the bed, strangely enough. I'll double check and try with homing first
Hey Peter, I have considered it. But I have 3 external drivers + I have a 48V PSU that I'd like to drive my steppers with :/ That's difficult with the blackbox
Hi David, I set up homing switches again. It's a bit stranger now.. The limits can be triggered by hand. (So they do work). Z homes normally, X and Y home at the same time, however Y doesn't move at all. However, it can be jogged to hit the limit switch. So there's some kind of fault in communication to the Y-driver? I can't seem to home individual axis to check. Kind regards,
Okay so, the Y driver is working. That's for sure, if there'd be something wrong there it also wouldn't jog. So I guess the next thing to try is to reflash the firmware. I remember having some issues with that originally so hopefully the issue lies there. Thanks again for all the help so far!
Post a grbl settings backup first so we can check if something is wrong Don't reflash without reason, Grbl firmware doesn't quite work that way You can reset the EEPROM if you want to using $RST commands - no need to reflash (unless currently flashed is some non-standard Grbl)
Peter, it is GRBL for esp32 and supports an A axis (-: (don't know if it is GRBL-HAL or some other variant) but i agree, do not flash until proven necessary. check first the homing seek rates, and accelerations. they may be too high for Y to keep up with causing a stall.
Yesterday I set the Y acceleration lower (to the same as Z = 50 mm/s²) but no difference. I'll also check homing seek rates. The flashing issue I just thought after reading "Homing Cycle Issue - Z Axis doesn't home" and I remembered that I had to flash it like 4-5x for it to actually work. Don't remember exactly why it wouldn't work from the first go.
Although if Accelerations are too high, I should hear a motor skipping, no? I just hear nothing.. I should maybe check if it's even activated at that moment
my question is, it is arcs only or everything? Code: G21 G90 G17 G54 G53 G0 Z-5 G0 X10 Y10 G1 Z-1 F500 G1 X-10 Y10 F500 G1 X-10 Y-10 G1 X10 Y-10 G1 X10 Y10 G0 Z5 G0 X0 Y0 M30 The above small bit of code will draw a 20x20mm square around the 0,0,0 point, going anticlockwise, starting at top right corner Load up your pen, home, set WCS, then run this code and see what happens.
Set "homing seek rate" to 50 mm/s instead of 200 -> no difference; same thing with setting "home locate feed rate" to 500 mm/s instead of 2000 Set "Y-axis acceleration" to 20 instead of 80 -> also no difference I can feel that the Y-axis motor is enabled during homing, just no movement. The test for drawing a square (this time a black marker) - it's a nice 20x20 square. But I ran the code twice, and it shows that it moves the original zero point 10 mm down. GRBL settings: $0=5 ;Step pulse time, microseconds $1=255 ;Step idle delay, milliseconds $2=0 ;Step pulse invert, mask $3=6 ;Step direction invert, mask $4=0 ;Invert step enable pin, boolean $5=1 ;Invert limit pins, boolean $6=1 ;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=0 ;Soft limits enable, boolean $21=1 ;Hard limits enable, boolean $22=1 ;Homing cycle enable, boolean $23=3 ;Homing direction invert, mask $24=200.000 ;Homing locate feed rate, mm/min $25=2000.000 ;Homing search seek rate, mm/min $26=250.000 ;Homing switch debounce delay, milliseconds $27=3.000 ;Homing switch pull-off distance, millimeters $30=24000.000 ;Maximum spindle speed, RPM $31=0.000 ;Minimum spindle speed, RPM $32=0 ;Laser-mode enable, boolean $100=200.000 ;X-axis steps per millimeter $101=200.000 ;Y-axis steps per millimeter $102=200.000 ;Z-axis steps per millimeter $103=200.000 ;undefined $104=100.000 ;undefined $105=100.000 ;undefined $110=2500.000 ;X-axis maximum rate, mm/min $111=2500.000 ;Y-axis maximum rate, mm/min $112=1000.000 ;Z-axis maximum rate, mm/min $113=1000.000 ;undefined $114=1000.000 ;undefined $115=1000.000 ;undefined $120=80.000 ;X-axis acceleration, mm/sec^2 $122=80.000 ;Z-axis acceleration, mm/sec^2 $121=80.000 ;Y-axis acceleration, mm/sec^2 $123=200.000 ;undefined $124=200.000 ;undefined $125=200.000 ;undefined $130=550.000 ;X-axis maximum travel, millimeters $131=570.000 ;Y-axis maximum travel, millimeters $132=100.000 ;Z-axis maximum travel, millimeters $133=300.000 ;undefined $134=300.000 ;undefined $135=300.000 ;undefined
The code I posted should return the pen to X0 Y0 after the draw. Did it do that? If not then Y is not capable of moving at 2500mm/min as given in the max rate setting. does the motor get warm, or hot? or stay cold? noises? wheels all running smoothly? if you disconnect and remove the leadscrew can you move the table around with a fingertip? if you jog in small increments so Y is furthest away from you, then set the jog distance to 100mm and jog it toward you, what happens?
Motor stays cold, it did not move back to X0Y0 rather X0Y-10. No strange motor noises at all, very smooth sounding. My mill is running on HGR20 linear rails, no binding at all. I'll try the 100 mm jog next. I tried that once before with a short distance and that seemed okay, but I'll let you know. Thanks again for helping me out! Yanou
I think it is jamming during some part of the commanded moves because it is not getting enough power. Pretty much all stepper motors get at least a little warm. I would turn up the power. If the motor gets so hot you cannot hold a finger on it for 5 seconds, then that is too much power, turn it down a bit (-:
Moving 100 mm prior to turning up the power moves 95.58 mm. Turned the power up from 1.9 A to - 3.1 A homing issue remained the same Moving 100 mm moved 101.42mm. Although these errors could also be because of the way I measure things (I just hold an extended caliper again the axis) Also added a video of the homing sequence. so in general, Z homes, pulls off, homes again. X-homes until it hits the endstop and then wait for Y to hit the endstop? to then pull of both again. The latter 2 (Y-hitting the endstop and then pulling off) don't happen. If I do it manually, it works. edit: the motor is feeling slighty warm to the touch now. X and Z are still bone cold as before
y should be homing with the table toward you, that is positive end of tool travel. hard to see the machine movements with the camera gyrating. if the switch is not there, then move it if Y is not moving then why not? too stiff? acceleration too fast? if Y is moving the wrong direction then A) make sure it jogs the correct direction then B) change the homing direction in the GRBL settings.
Hi David, Y should indeed be homing with the table towards me. The video wasn't very clear, I agree What I tried to show is that, Y doesn't move at all. I can jog it around easily, Even when setting accelerations very low (tried 10 mm/s² without not even the slightest change), it does not move during a home sequence. I tried to show that in the video, as well as that the homing sequence was still going, i.e. did not fail or anything in software. I played a bit more with it and found out: if I attach the Y-motor to the X-drive (with X-Dir,Pulse) attached -> It works and homes. if I then swap the Y-Dir and Pulse over -> Doesn't work anymore. X motor on the original Y-drive (with it's proper Dir and Pulse attached) works fine though. So I'm really starting to think it's a controllerboard(/maybe firmware?) issue. Since it's clearly an issue there, I know the wiring works, because I've measured it out already at least 5 times... EDIT: And all now just replaced it with new wires with no change.
