If you have EMI issues it would show up during some test cuts too - random stalls, usb corruption, false hard limits alarms etc - see the symptoms section of docs:blackbox:faq-emi [OpenBuilds Documentation]
I did a test cut, and something definitely is not right here. When jogging 1 axis at a time all is fine, but in this g code there were some steps lost on the Y-axis. That probably happened in the stutter, now to find out where the stutter comes from
Best news yet - reaffirms the theory that the machine is unable to move - and that the control system is fine. Time for a mechanical teardown to see what's loose - that still looks like classic slippage from loose shaft couplers, loose leadnuts etc
I checked all of that, and everything is tight. Checked for backlash, nothing there. Loosened and re-tightened leadscrew nuts, and couplers, also all fine.
This is one of those cases where the symptoms says the above statement is not true. Something is slipping (or binding) instead of moving properly. The only question is what and that can only be found by systematically inspecting your machine
Not always... rails versus wheels - could just be binding first. Less forgiving to installation alignment than V-Wheels
I did align them within 30 microns, and the minimum is 40, so that should be good. When there werent any screws installed, it was buttery-smooth, so the rails cant be the issue. I also tried adjusting the torque on the blackbox, but that also made no difference
Disconnect the motor shafts (mechanically) and spin the leadscrews by hand - feeling for play/binding spots/etc (Don't spin the motors - backfeeding your stepper drivers can damage them)
I did this on the Y, and they are spinning freely. I also pressed home all axis, while the leadscrews were disconnected. The next thing happened, as can be seen on the video: The motors all stuttered, but when X reached the switch, and stopped moving, it stopped stuttering, and moved freely again.
Just comparing your settings to the Grbl defaults, and yeah that $1 will be the stutter... Defaults in Grbl is pretty good. Steps per mm, acceleration, max rate, any direction inversions (or just build the machine correctly so you don't need inversions) and your homing/limits preferences are about all you need to change. Don't change advanced settings like timing, junction deviations, arc tolerances etc Perhaps try a clean set of Grbl defaults (Reset EEPROM) - Fix any motors spinning the wrong way round - by fixing the wiring order (yes, you can use $3 - but its one less thing to remember to change) - Put the limits all at axis maximas (see Frequently Asked Questions · gnea/grbl Wiki) - yes you can change it but if its "as expected" its easier to troubleshoot - Don't change any values other than Steps per mm - Try enabling Homing again - Test homing
Alright, I will change that! I did built the machine correctly, but RatRig, from which I bought the machine, has the switches located on different locations than the stock workbee. I will try this, and come back on it!
Doesn't matter too much, but still here's something odd, so lets do it the Grbl way (not the manufacturer way) just to take bring it in a little first
Only problem is, I don't have enough wire length to change to switches to maximum, so is there a workaround for that?
Now i did a fresh install, reset everything, and switched the wires arround so the jogging directions are right. When I press home, x goes to right, and y to the front, while they need to go to back-left. So I invert home X and Y, but then Y comes forward, untill X hits the switch, and then Y reverses, untill it hits its swich. Then Y backs off, and it is finished, but X doesnt back off. Is there a way to send the machine to back left?
First make sure its Jogging the right directions! Machine has to comply with cartesian standard in its own moves FIRST! X+ = to the right Y+ = to the back of machine Z+ = up and away from the bed If not, fix it with either the wiring (recommended) or $3 parameters (Use CONTROL's toggle switches - easier to understand that calculating bitmask) Only once it JOGS the right way, can you move onto homing $23 doesn't reverse the axis it tells Grbl "I put the switches on the wrong side for these axis" - ie at axis minimums not axis maximas. Default ($23=0) expects all three switches at axis maxima But yours is Left (i.e X-min), back (Y-Max) and Z-top (Z-Max) So you need to apply a mask that only inverts the X switch position as its not where Grbl would have preferred it. From the Grbl wiki, that would be: $23=1 $23 is not set by observation, but by facts -- where is the switch located on the machine. The "normal" position is axis maximum. Any switch placed on the other end is "inverse" of the expected normal position
Looking over machine parameters, also set Max Travel - or later when you are far away from the switches and try homing it will error about not finding the switches within the allowed distance (as machine is bigger than 200x200mm)
Alright! I have the jogging sorted, that is all fine, I will apply that mask with no. 1, hope it works!
