It all began when I decided I would give Universal Gcode Sender a try on my S3 XL. Carbide Motion (V3.364 on a Mac) had been working great for more than 12 months. UGS worked OK, homing and everything but crashed into its mechanical limits on the X axis even though the x max travel ($130) was set to low values. Didn’t try the y axis.
Went back to Carbide motion and the same happens. Regardless to what I set $130, the carriage crashes into the left hand Y rail. Obviously something is wrong somewhere but I am out of ideas. Appreciate any thoughts.
(The bottom 4 or 5 lines have been cut from the image below but are viewable by clicking on the image)
Thanks Tito, I tried setting $20 to a 1 and that really messed things up. As for $21 I think it should remain at a 0 (edited), I quote from Configuring GRBL v0.9 on Github:
$21 - Hard limits, bool
Hard limit work basically the same as soft limits, but use physical switches instead. Basically you wire up some switches (mechanical, magnetic, or optical) near the end of travel of each axes, or where ever you feel that there might be trouble if your program moves too far to where it shouldn’t.
I had a typo in my previous “As for $21 I think it should remain at a 1” should read "As for $21 I think it should remain at a 0."
According to the GRBL blurb it should only be set to a 1 if there is a limit switch on the axis.
my .9 foo is getting rusty, but I’m pretty sure soft limits on any version and CM do not mix… I’ve NEVER had luck going between CM and another gcode sender. CM fiddles with things too much in the foreground and gets confused by some standard grbl settings. Once you move away from CM, stay away, and if you have to go back, make sure to do a “send config” through CM before you start running jobs.
Any chance you can move yourself up to grbl 1.1??? (I know, I hate the suggestion of upgrades as a fix, sorry)
Thanks Evan. I note Rob Grzesek comment in the link you provided:
Based on many many support calls and emails we have an official public service announcement from Carbide 3D:
Do not enable soft limits.
That being the case what then is the point in setting $130 and $131 (x/y max travel)? Or are these independent of setting soft limits $20?
My problem remains and that is the carriage slams the left hand rail regardless of my $130 setting even with soft limits off ($20=0). It didn’t do that before.
Thanks Adam_Xett for youur suggestion
Any chance you can move yourself up to grbl 1.1??? (I know, I hate the suggestion of upgrades as a fix, sorry)
I have been mentally toying with the idea of moving up to GRBL 1.xx and CM4 but haven’t had the courage yet. Perhaps now’s the time in spite of the warning on the Carbide Updater site
This is the bleeding edge. Consider yourself warned
But, many others seem to have done so effectively given the ‘noise’ on the subject on this forum seems to have disappeared of late.
I was able to pretty simply adjust my table size in CM3/Grbl 0.9 to get things centered and not hit the extreme far edge — CM4 seems to be a bit more conservative and things just fit.
Wait, why would you want $21 to be set to off? The only way that makes sense is if you do not have limit switches installed. Is this the case? I have limit switches on the x, y, and x axis so I have $21 set to “1”.
For what its worth, I tried out both UGS and bCNC recently because I wanted so see what some of the other G-code senders were like. I did not like UGS. I like bCNC, but I had a similar issue as you. When I set up bCNC, the machine would home fine, but I was able to smack the axes into the physical limits by jogging. bCNC was not recognizing my limit switches. I kept trying to set $21=1. Then I realize that the interface in bCNC requires a two-step process. I have to click on $21 to set the value to 1, then I had to actually send that command to my control board. After I figured that out, it worked fine.
Seems to me since it happens in CM and UGS, that its a settings problem in your GRBL settings. Does homing work for you? I still feel like this is a problem with hard or soft limits.
Ultimately, I’ve been on GRBL 1.1 CM 4 for a two months or so now and have had no issues. I also had no issues when I went back from bCNC to CM 4.
Thanks Will and Evan, I think I will go ahead and take to plunge and install CM 4 and GRBL 1.1.
Thanks also Evan. I quote from the Configuring Grbl v0.9 from the Github web site:
$21 - Hard limits, bool
Hard limit work basically the same as soft limits, but use physical switches instead. Basically you wire up some switches (mechanical, magnetic, or optical) near the end of travel of each axes, …
The operative words seem to be near the end of travel of each axes so unless one has limit switches at each end (for a total of 6 switches) $21 should be = 0
Yes, but bottom Z-axis is sometimes omitted. Certainly no one has worked up a suitable design for the SO3 carriage which I’m aware of (but I’d love to see one).
Another consideration is false positives — you should probably upgrade to shielded wire for the switches.
If you have a stock S3, XL or XXL, $21 should be set to 0 (off)
If you have a stock S3, XL or XXL and use CM as your gcode sender, $20 should be set to 0 (off)
If you have switches on all three Axis’ (standard S3 homing switches, for example) set $22 to 1 (Homing enabled).
The above three settings are the same between grbl .9 and 1.1
If you are NOT using CM: You can enable soft limits ($20=1) and set #130, #131 and $132 based on machine size.
If you are going to enable soft limits ($20=1), then you really should have a reliable way of machine-zeroing. Homing and homing switches are the usual way to do this.
If you’ve moved between gcode senders at any point and need to go back to CM, you must do a “send config” from CM before running any jobs.
If all the above are followed and things are still amiss, start checking hardware.
