Will I’ve done all that, it’s off by about .25mm to 1.5mm on the Y inconsistently after it rehomes and I’m cutting aluminum. The zero coordinates don’t change in the system but it’s off. And with aluminum, it’s noticeable with crashes or bad secondary cuts, I was hoping the new board would have changed something. The belts are new and consistent, always start with it pulled up front, etc.
Do the limit switches need to be adjusted?
Most interesting is I was cutting some 1 inch exact blocks for a jig out of half inch aluminum, and without rehoming they were within .001 accuracy. So the machines capable, I’m just chase in the rehoming because it’s hard to tell if it’s off by a half a millimeter or a quarter millimeter even checking the zero. And then it ruins a part
Please let us know about this at support@carbide3d.com and we will do our best to work through this with you.
If I have to rehome my machine during certain operations, like a trace or finishing operation, I generally end up scraping the part. I can confirm and rezero if necessary, but things may be marginally askew. Repeatability may have decreased after switching mechanical switches to proximity.
I suspect you could dial it in a little, but I am not sure how persistent it would be. Loading and unloading machine. Moving the machine slightly on its table ect.
Some 3D printers and entry level stepper driven CNC machines overcome this issue by skipping limit switches all together, instead relying on hard stops and electrical feedback from the stepper
I seems that I am finding a pattern that may be software related? If I run a single part of a job and it finishes and re-homes the ZERO stays intact consistently so far. But most of my projects have 3-8 operations and 2-4 tool changes. If during an operation I pause the job and STOP then it re-homes and about 50% of the time or more the ZERO is off? This points to a software glitch IMHO. Coming from the PROGRAMMING/IT world, the same physical elements producing different results is a error typically in the way an Application is processing information. I am trying to find the exact steps to reproduce 100% of the time.
Still seeing random issues with this, if I pause and stop an aluminum job, 90% of the time is off, wood seems to be hit or miss. So I have noticed that when aluminum chips get on the rear proximity sensor sometimes it turns red and then all hell breaks loose in homing…
So is there a chance that metal chips on the proximity sensor can trigger the Y inconsistently?
I also find this on a 3XXL with mechanical home switches.
The homing is repeatable but only to about 0.25mm which is more than enough to mess up a job.
The re-home after a STOP is unnecessary and very irritating, a STOP is frequently just a user wanting to stop the toolpath and re-send from CAM.
Also, the consistent loss of comms and re-home if you hit “Resume” before the STOP button enables is similarly irritating.
I had to re-home 4 times on a single job today between those two issues.
I think @carbide needs to update motion to allow us to pause/stop and reload new code without rehoming. This would make all our lives easier.
I think the issue relates to hardware, but that’s only based on my observation. As mentioned above, I found my error possibly more noticeable after installing the proximity switches. These switches aren’t exactly examples of industrial reliability. Maybe you could swap them for a precision example. And that is just one area to consider.
The switches I use on my other machines are around $100 per, and still relatively inexpensive and potentially imprecise. The servos compensate, comparing their position to the homing switches open signal. If their perceived location is within the programmed acceptable range, they maintain it. If there is a disparity, I get an error. I can tell the machine to go to a preprogrammed offset, any time, any day, and it will go to the same location on a fixture ect every time. Different hardware. A lot more money. Shapeoko is what it is, frustrating at times, but it’s affordable and forgiving to user error. I keep it at my house, and while I’d much rather use one of my 3phase machines, I also enjoy being able to stay home, drink a beer, pretend to work, and scratch my pet Pig.
Because Carbide Motion sends the machine home after a program ect, I do not use Carbide Motion. Carbide Motion is developed for a general purpose. I’d suggest switching to something else, possibly better suited for your needs. I am currently using GSender, its not all hashed out yet, but it’s pretty well thought out, and seemingly under constant development.
Absolutely,
I got hardware that was good value for the money I paid, part of that is that I don’t expect to be able to come back a week later, power up, home and be < 0.1mm accurate on the position, I re-home and that’s fine.
What seems like a really simple ease of use fix though, is to drop the re-homing on a STOP in the program which is generally not necessary.
I suspect it’s there for the cases where a new user has crashed the machine, hit pause and then hit stop and Carbide want to make sure things work ‘normally’ from there on. I would very much like a config checkbox that says “only re-home when I tell you to” 
Totally Liam, that is all we would need and I think 90% of the time all would be good on my end. I cut a Zero hole for any part that I can, but once I cut the center out of a part that uses that as Zero , I am SOL
Can you explain this?
I totally understand your frustrations. I’ve seen the exact same problem. My machine will drift 5 mm consistently after homing and I’ve chased belt stretch and calibration all over the place just trying to get the machine to accurately locate simple things like bored holes for the waste board. I didn’t chase these issues with my SOXL3 but my gut tells me the much longer belts amplify these issues on the XXL Pro. I have to be super careful about where I’m cutting on the machine because its more accurate in different areas but then I’m left out if I want to do larger parts that need more precisely located features. The greatest flaw with the SO4 Pro is they didn’t think to improve the belt tensioning system to make it more consistent. There was enough good belt tension designs from 3d printers out there that I’m really surprised in the development that they didn’t think to improve something that fundamentally effects the accuracy and squaring of the machine. If I could buy it over I would have gotten the xl instead of the XXL for the type of things I do and just lived with the reduced work area. I’m still using my SO3 more than my 4 because I can’t seem to get it to perform as accurately, even though it is more rigid.
Once I have it set I find it’s really accurate On a job… rehoming seems to be where it gets jacked. Most jobs I run have 2-4 tool changes so as long as it can keep rolling I’m fine, but any need to stop and it’s pray time and re-zero
Anyone who has precision/repeatability issues w/ their machines should contact support@carbide3d.com — I suspect that the belts either aren’t tensioned sufficiently or that they’ve developed some sort of problem, in which case we will replace them.
I re-zero my machine while working on it constantly since I rarely get uninterrupted time to work on projects and am able to do things such as rough out fingerjoints w/ a large tool, then run a series of perimeter passes to add dog bones w/ a smaller one and have things line up as expected.
Will i ran IT development firms for 25+ years, before I started making Porsche Parts fulltime, so I have done 1000’s of hours of testing, chasing strange and challenging bugs.
From what I have narrowed it down to is either a software issue based on a certain process = start job/pause/stop/rehomes > zero off. Or a proximity Switch issue (WHICH I THINK IT IS ON THE PRO)
I have been chasing this ever since I started to cut metal and have spent the last month focused on understanding when it happens, and it seems to be switch related.
Or I really think it is the proximity switches when cutting metal, because with wood I almost NEVER have an issue, the Y axis has the proximity switch with the sensor area placed UP, which by all terms would be inconsistent since the “contact” with the side metal plate could go back further or stop early if there is a bit of metal sitting on the switch. WHICH IS EVERY TIME WE HSM aluminum.
This seems to hold true as to why the X and Z are NEVER off, the switch is placed so that a consistent plane is activating the switch and placement doesn’t allow it to collect metal for the most part (also easier to clean as it is right front and center. Also in all the testing I notice that many times during a job the Y sensor is triggered RED because of metal on it…
RECOMMENDATIONS:
1) MOVE THE Y PROXIMITY SWITCH: Can the Proximity switch for the Y be moved to the front left corner so it is easier to inspect and keep clean when cutting metal
2) Change the orientation of the proximity switch on the Y axis so that it has a consistent flat plane to read off from like the X & Z
3) ADD a software PAUSE/DON’T REHOME option in Carbide Motion. I know many have said use a different G-Code sender, but with 4-5 tool changes per job the setup to make the bitsetter work is too much right for me to test and trouble shoot in production. Also I really believe the switch is the issue
Let me know if I can help test things, I have been trying to find a way to home in the front right to test
My work is too big for a vice. On Shapeoko when I feel like caring, I model a 1-2-3 block, or a block of stock with a quality hole into the design. Indicate the block square or use a hole center finder, the later being generally preferable in my opinion. This will be setup 0. If I was using a vice, softjaws ect, I’d use model of setup and pick a feature, that would become setup 0.
Then it’s just a matter of firing up the steppers in as repeatable manner as possible. I push my gantry into y hard stops. Never going to be perfect, but probably good enough for small parts. Find zero, and move forward.
Think of it like moving the knee on a big ol Bridgeport style machine, or many other machines. Reindicating zero just part of the gig.
Some fine people on this forum, like Neil Ferreri, have already contributed their hard work. Macros and the like for other GRBL Senders to allow things such as tool change offsets. You will also get, in my opinion, a better work flow, less handholding.
Thanks I will try to so some testing this weekend, what GCODE sender would you recommend? I am trying to edit the NC code to an M0 at the end so the job won’t rehome. Not sure if that will fix it when we pause and STOP too?
I’ve gravitated towards CNCjs and now Gsender, which is a fork of CNCjs. I run Gsender on a Rpi, with visualizer disabled, have found it stable.
You’ll have full macro support, a great firmware menu, and no additional behind the scenes machine behaviors, like unrequested homing ect.
I’d guess you can not modify the behavior of CM, it is probably programmed to fit Carbides idea of best practice and to the benefit of support. But I don’t know, I haven’t used it much.
