question - i’m getting a bit tired of having to “home / initialize” the machine every time i start up a new session in CM.
given that i’m going to set my zero point when i have placed the bit where i want it - i find this process super annoying.
I find it even more annoying when CM just decided to stop working, and i can’t move the tool head and i have to restart the program and thus initialize the machine.
fwiw i have done some work to ground the machine, use the ferrite cores on my USB cables and so forth. but it’s pretty much guaranteed at this point that the start up on a given day will require homing it a couple of times.
it’s also annoying when the tool head gets to a certain point at the furthest reach of the X axis - that that is when CM will conk out.
info, advice, suggestions, help all welcome. ideally looking to just turn off the homing default at this point on CM4.
also it’s pretty much guaranteed during homing cycle CM will stop 4-5 inches shy of the home in back right and stop. in this case usually i can tell it to home again and it does so ok. but even so what’s this about? i did catch the screen say “the door was open” very briefly - does it think i’m running a nomad and there’s a missing interlock?
That CM4 still crashes is likely part of why it’s still in beta — please contact beta@carbide3d.com w/ all the specifics of your situation and results of your testing and hopefully they can use that information to improve the software so that it can be released.
Wait a second… you say it “crashes” when it’s way out at the end of an axis? As in, it’s close to the sides away from the homing switches? If so, you may be hitting the soft limits in GRBL which is different. The issue then is that GRBL is trying to protect the machine, and stops taking commands. To clear this state, it needs a little MDI voodoo…but CM is not crashed/stuck.
I found that the configuration pushed by CM for the XXL sends incorrect soft boundaries for the machine. This, among other things, causes the machine to fail a homing cycle if you start it from the front-left corner of the tablet. I believe it’s going to be addressed in an upcoming bugfix. Not sure if this applies to you (XXL) or not…
Thanks for this Mike, I’ve been having the same issue since I did the CM4/Grbl1.1 update a few weeks ago and didn’t really know how to describe/re-produce the issue to report it, this makes a lot of sense.
After you calibrate for belt stretch, you can extend the soft limits - I adjusted and snuck up on them until I didn’t trip them until i was pretty close to the actual travel. Be aware the soft limits should not be enabled if limit switches are not enabled.
Here is where to set the soft limit travel:
$130=225.000 (x max travel, mm)
$131=125.000 (y max travel, mm)
$132=170.000 (z max travel, mm)
If you see the machine not home all the way back to the switches, and report a homing failure, it’s because the homing travel needs to be made larger. I don’t remember exactly what to set to manage the total travel it can use when homing. I’ve seen some people need to adjust it. There might be something in the forums here.
Back to the regularly scheduled program…
To clear the alarm state you get in when you hit a soft limit:
$X
Then,
$H
to home. As I understand it, you should always home from the alarm state - that alarm state can be entered from a number of conditions, some of which are because the machine believes it has reached an unsafe state or lost it’s position (like, say, crossing a soft limit), but the homing cycle will bring it to a known good position.
Hopefully that helps, and isn’t riddled with mistakes