I have run flawlessly for months with the Blackbox using the OB control. Yesterday I started getting odd error messages when running my surface zero macro. When initiated it would go into a lock out state and I would be forced to hit OK and then run the macro a second time and it would work. I did not capture the error message. This happened dozens of time throughout the day. Today, the motion in Both X and Y are not working properly. When trying to jog in either direction the motors stall. I have been able to get it to work but had to go in and change my Grbl $110 from 4000 to 2000 mm/min and $111 from 4500 to 2000. is the Blackbox going bad??? Any help would be appreciated.
Can you jot them down - each different error message offers clues to exact causes Without knowing what the errors were that led to Grbl being in an Alarm state (and thus locked out) - it would be hard to offer more information Any chance the power supply started failing? - measure output while a job is running, see if it dips below 24v under load Any other changes, Grbl settings corruption? Or changes that was applied? - adjusting acceleration to be more aggressive can lead to stalling for example
I my mistake on not capturing the codes. Will do that next time I see them. I just checked the power supply output. It is 24 volt at rest and then will bounce back and forth between 23.5 and 24 when running a gcode.
I’m not seeing anything out of the ordinary. Acceleration is at 100 mm/sec2 for each axis. That’s where I have had them for months.
Ok. No error message this time but when I initiated the z zero macro the z axis shot down at max speed and slammed into the probe. Nothing broke since it stopped when making contact however the work coordinate position read 528mm. Normally it’s 42. when initiated the second time it went nice and slow just like always and zeroed correctly. I am baffled.
Yes newer versions have a much better Probe Wizard, please do use that instead: Are you by any chance using a very long USB cable / extra Extenders or hubs between computer and controller (serial corruption)
unexplained speed and distance in the probe indicates a USB corruption or inch mode instead of mm. put a G21 at the start of the macro to make sure we get what we expect. also, that macro should have a G91 at the start so that the probe runs relative to the current position
I will make the Thanks for the info on the macro. I will make that change just in case I use it again as I transition to the OB probe wizard. The USB cable is 3-5 footer. Do the go bad over time?
Not really no, as long as its a good quality cable, shorter = better As explained here docs:blackbox:faq-emi [OpenBuilds Documentation]
Do we have any idea why the speed of movement had to be changed in the settings for the unit to function correctly after months of great service?
Something binding up from cutting dust settling on moving parts? Do an inspection of your mechanical components
I did a complete cleaning and inspection yesterday and did not find anything. If this were the problem It would be very odd to have both the X and Y show the same problem. That’s why I’m leaning towards electrical issues. Is it possible the muscle board is bad?
Bad muscle = no movement at all We've never seen one slowing down - that usually points to a settings/mechanical issue. In particular the odds of 2x Y and 1x X driver having the same issue is extremely remote. Stepper drivers tend to fail one at a time if they do. That was why I enquired about the PSU earlier.
Here is a video at 2000mm/sec2 in Y and a second one at 3000 mm/sec2. the results are the same in both X and y. Prior to the issue starting two days ago I was running with both settings at 4000 without issue.
Sorry about that. Here you go. $0=248 ; Step pulse time, microseconds $1=255 ; Step idle delay, milliseconds $2=0 ; Step pulse invert, mask $3=0 ; Step direction invert, mask $4=1 ; 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.020 ; 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=100.000 ; Homing locate feed rate, mm/min $25=1000.000 ; Homing search seek rate, mm/min $26=250 ; Homing switch debounce delay, milliseconds $27=5.000 ; Homing switch pull-off distance, millimeters $30=1000 ; Maximum spindle speed, RPM $31=0 ; Minimum spindle speed, RPM $32=1 ; Laser-mode enable, boolean $100=197.855 ; X-axis steps per millimeter $101=197.941 ; Y-axis steps per millimeter $102=199.463 ; Z-axis steps per millimeter $110=2000.000 ; X-axis maximum rate, mm/min $111=3000.000 ; Y-axis maximum rate, mm/min $112=2000.000 ; Z-axis maximum rate, mm/min $120=100.000 ; X-axis acceleration, mm/sec^2 $121=100.000 ; Y-axis acceleration, mm/sec^2 $122=150.000 ; Z-axis acceleration, mm/sec^2 $130=790.000 ; X-axis maximum travel, millimeters $131=760.000 ; Y-axis maximum travel, millimeters $132=190.000 ; Z-axis maximum travel, millimeters
Grbl default is 10, see gnea/grbl This will slow you down a lot, delaying the step signal 24x longer than needed. BlackBox fine, Grbl Settings the root cause Laser mode is on, is it a laser machine? Grbl default is 0.010, see gnea/grbl Should be able to do 5000 or more after fixing $0 Keep Z max rate lower, routers are heavy, gravity works in the vertical axis Play with these, could probably go even higher once $0 is fixed
That fixed it! Thanks guys I did not go in and change the $0 ever. How could this change on its own? The unit is set up as a router but do run with a laser add too. Chuck
Maybe an accidental command sent while troubleshooting, or a misclick of the mouse into the settings tab
