Hello! Apologies for adding another CNC setup thread but I'm struggling to get my recent CNC build up and running. I'm running a blackbox X32. As it's not an openbuilds machine I've selected custom machine in the openbuilds control software. I believe I have everything wired correctly (famous last words). When trying to home, I get Alarm 8. The Z axis moves about 5mm and then stops. Giving me the alarm. [19:04:19] [ ALARM ] ALARM: 8 - Homing fail. Cycle failed to clear limit switch when pulling off. Try increasing pull-off setting or check wiring. [ $H ] I'm using 3 wire inductive switches. docs:blackbox-x32:connect-npn-inductive [OpenBuilds Documentation] I've checked my limit switches in troubleshooting and they do all say triggered but this does switch to "off" when I manually test them, and when I manually jog the machine close to trigger them. I've tried inverting the two outer wires to see if this flips things but it then goes to "off" and the switch doesn't work when manually tested. I've read other forum posts that state it could be a short or damaged switch, but the switches all work, they just seem to be reversed so I don't think there is a fault with the switches or cable themselves. Am I doing something painfully obvious wrong? Thanks
I've also seen some people control the coolant from the open builds control software, can I connect that direct to the blackbox, or do I need this IOT relay?
Coolant port is 24v (max 3A). If your coolant pump is mains voltage instead of 24VDC, yes add IoT: see docs:blackbox-x32:connect-coolant [OpenBuilds Documentation]
I got my spindle up and running today, I followed the video that everyone seems to mention. Though When I turn the Spindle off with the M5 command or the button in openbuild control, the spindle doesn't turn all the way off, it sits at 72RPM according to the read out. Anything obvious I'm missing? I've changed the GRBL settings like is mentioned in the video. Thanks
Follow docs:blackbox-x32:connect-vfd [OpenBuilds Documentation] and wire up your enable/arm (probably currently a jumper wire) through the relays
Everything seems to be working well now thanks very much for the help Peter! I've just calibrated the machine (Will do it again just to double check my numbers) However one thing I did notice with all Axis'. When Jogging the machine, moving large distances such as 100mm seems dead on, but when jogging small distances, 1mm, 10mm it doesn't hit dead on. It can be a few .10 or .01 out. Does that sound like something that can be remedied?
Might be acceleration or max rate maybe too high, causing stalling - see https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#110-111-and-112--xyz-max-rate-mmmin and https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#120-121-122--xyz-acceleration-mmsec2 - once reliable (no stalls) - recalibrate. If issue persists, could be mechanical (slipping shaft couplers, etc recheck grubscrews and other mechanical aspects)
you dont say how far off the short jogs are. if the errors are pretty small it might just be step roundoff. my machine does 0.025mm per step on X and Y, so jogging small distances can have roundoff error where it will land up some whole step count away from where it started, but some portion of a whole step away from the commanded position. Math will make you its ***** (-:
So just to give you some context on how far the Axis' moves. I am aware these are very small issues (Looking at the distances now) but just trying to get everything running as best it can before jumping in to projects. I've had a a CNC previously but this is my first "Good" one so would like to make sure I'm starting on the best foot. Like I said moving larger distances seems fine, 100mm seems to have the Openbuild control software read exact 100mm increments. Smaller like 10mm and 1mm seems to deliver an odd step sequence. But it does seem to land on the next 100mm increment when it gets there. I just used a random starting point on my machine hence the, 200+ and 400+ for the axis positions. Moving 10mm at a time results in this for each axis - Y: 200mm, 210.002mm, 219.997mm, 229.999mm, 240.001mm, 249.997mm, 259.999, 270.001mm, 280.002mm, 289.998mm, 300mm X: 400mm, 409.999mm, 419.998mm, 430.003mm, 440.002mm, 450mm, 459.999mm, 469.998mm, 480.003mm, 490.002mm, 500mm Z: 0mm, 10mm, 19.99mm, 29.99mm, 39.99mm, 50.001mm, 60.001mm, 70.001mm, 80mm, 90mm, 100mm Moving at 1mm at a time results in this for each Axis Y: 200mm, 200.998mm, 202.002mm, 202.999mm, 203.997mm, 205.001mm, 205.999mm, 207.002mm, 208.998mm, 210.002mm (If I jog back 10mm from here it goes exact to 200mm) X: 400mm, 400.998mm, 402.003mm, 403.001mm, 403.999mm, 405.003mm, 406.001mm, 406.999mm, 408.003mm, 409.001mm, 409.999mm (Again if I jog back 10mm it goes exact to 400mm) Z: 0mm, 0.999mm, 2mm, 2.999mm, 4.001mm, 5mm, 5.999mm, 7.00mm, 7.999mm, 9.001mm, 10mm (Same here jog back 10 it goes exact to 0mm) So it seems the machine currently does get back to the starting position, but I'm wanting to make sure something isn't wrong in between. I'm just going to investigate this stuff now on the machine.
Is there potential for it to be a software bug? I switched to "Inch mode" just to check and I don't seem to be losing any steps on the pre-set incremental moves with the openbuild software. It seems to be giving me exact movements. I'm absolutely fine if this is a mechanical error that I need to fix but just wanted to see if that is a possibility. So far I have adjusted the Acceleration and Max Rate on the X axis, both making it slower and making it much faster, and when moving in Millimetres it still seems to give me the same results as posted above.
DRO does round off to I think 3 decimals just to keep display less cluttered, Firmware also "rounds" to nearest step, so its "as good as it gets" in that sense. If it can't reach a position exactly because its between steps, it can sometimes show up in the DROs. DRO is "accurate" in the sense that machine is where it should be, displays may round up or down, firmware may stack for steps, but thats as fine a move as it can do to get you as close to where you want it to be as it could, its just reporting it did. Particularly in motion systems where the steps per mm has decimals etc - it has to move steps less or more to compensate for partial steps and all that sort of trouble internally... But it does it beautifully to never go further off from where it can be. I thought you meant you were checking your moves in the real world... If you were checking the actual moves it would be mechanical, but sounds like your talking more about the DROs
DRO refers to the display? I wasn't checking things physically, just going off what the openbuild software was telling me. I checked the couplers, grubscrews etc, and all seemed fine.
Yes: [D]igital [R]ead [O]ut Yeah values onscreen has no bearing on mechanicals. Its only telling you the truth. And the combination of hardware + steps per mm settings dictates that reality for you. It can't always move to the exact micron you want, the stepper motors has to stop on a "step" as close to the position you wanted
Perfect, thanks very much for your help again Peter. I don't expect absolute precision I know there are variables, but just wanted to check this. I'll continue to monitor things as I learn this new machine and interface.
this is normal floating point roundoff error, you can ignore it, the machine is going to the closest step and you cannot get better than that (and no, higher microstepping will not help, will usually make it worse ) the only way to get closer in the displayed numbers is to use 64bit floating point numbers or one of the fancy currency formats (designed to deal properly with roundoff on money transactions) that ESP32 microcontrollers do not support, and these are just the numbers coming back from the controller being displayed. A standard 32bit floating point number is imprecise in predictable ways (-: (I have spent a lot of time in my 30+ year programming career fixing/fighting/working aorund exactly this thing) A stock OB machine will be doing 0.01mm per step, so displaying to 3 digits is trying to show something that does not exist since it cannot do 0.005mm movement. If you have calibrated over the longest distance you can measure accurately (100mm is too short, really) and have repeatable distances going from 0 to 500 (or whatever fits the axis), then the machine is good to go. cut something useful today, it will be fine (-: more here Round-off error - Wikipedia
