So I have upgraded to V3 (R355) of Carbide Motion for my Nomad 883. It seems to have fixed the bugginess around losing my z-axis zero which is great. And it also incorporates a button on the GUI for getting to the MDI screen which I love! However, after I go through the homing process, then jump to the MDI screen, it always says “NOT HOMED” in red.
Problem: I am using the edge finder to zero off on my work piece. I can confirm that it is an accurate method for finding edges. But it is a little sketchy to use right now. The machine homes, then I toggle to the MDI screen to get the spindle going. Once I exit back to the jog screen it thinks that it need to home again! So it does so with the spindle going. Even though the edge finder is blunt, it is not great to do the touch off with it spinning. I tried to trick the sensor but it either freezes or kicks an error. Can this be fixed or has anyone found a workaround?
I have a shapeoko 3 running control board V2.3, and my machine is loosing homing position( I have limit swichts and use carbide motion in mm). I run a job and then when I press to go to currently position on x & y, it is not at the same place it was. Any thoughts?
Above is one of the exemple. The hole should be in the middle. I run one g code and then another.
Please post the exact command sequences which you used, note what you expected to happen, and note what actually happened — it may be a misunderstanding about being in relative vice absolute mode (check the G-code file to see what mode it leaves the machine in).
I already checked the pulleys and belt tension everything seems fine.
I use Vetric aspire to generate my g code with instructables post processor. After homing and setting the zeros I started a job. Then when I go to currently x and y position and z+6mm position, it was the same at the first job. It is “loosing” the position.
I did this holes you can see above in the photo to see where I started and you can see is not in the same place, but in the carbide motion is supposed the same x and y position.
Try using the GRBL 8 post processor and see if that works for you. I had a lot of problems till I did that with VCarve Pro. Unexpected and very odd behaviors were noted.
When you save your toolpaths in Aspire, there should be an option to change your post processor. It looks like they have change the name to just GRBL in VCarve Pro so I would guess it is the same in Aspire. Sorry for the confusion but it used to be GRBL .08 or something like that. I never look now since I have it setup for all my toolpaths when I save them. Check it out and see if it is there.
I’m having an issue with my newly installed homing switches on my S3, maybe someone can point me in the right direction. Got the hardware installed just fine, tried to run the homing sequence, and discovered the $h command didn’t work at the MDI prompt in CM (well, it shows in the log that I sent the command, but the machine doesn’t respond). The command /$h does work. Is that ok? Always worried about syntax. Is there a reason using $h (per the instructions) didn’t work? Toggling the homing setting worked just fine with $22=1, no slash required. I’m running the latest CM release on Windows (updated CM just yesterday).
Anyway, with /$h the machine is now successfully homing, but I’m getting odd jogging behavior. Once I home the machine, it ends up at -5mm offset on all axes. When I try to jog in any single direction, sometimes it will move all axes a short distance and then continue in only the direction I’m trying to move, and sometimes it will just start moving and not respond, moving all 3 axes away from the home point until it crashes.
Same issue happened when I tried to set a work coordinate system using the guide in the wiki (for instance, I sent /G10 P1 L20 X-.129 to set the X-axis of WCS1/G54, when the tool is offset by -.129in from where I want it to be). I’d set one axis, try to jog, and the machine would move in a totally unexpected direction until it hit the limit of travel. Now that I type the command out again however, I realize that my offset should have been in mm, not inches!
I see in the wiki that G54 is reserved by CM, is that causing my issue? Or is that only reset after a restart?
The -5mm offset is normal (and settable) - if it sits against the switches it will throw you an error when you start it back up. It knows where the machine zero is, it’s just helping you out so you don’t have to move the machine by hand before you restart it. (its the $27 setting, homing pull off, mm)
Motion uses G54. It’s reserved, as you say. It does rewrite commands on it’s way to grbl (which is why /$h works, and $h doesn’t - CM thinks you don’t have homing, there’s a setting for this and yours is almost certainly off - it’s a CM setting, $22 is the grbl setting)
Thanks. I figured the offset was normal, and found the setting. Also realized I needed to ALSO change the homing setting in CM, which was not in the install instructions I printed out a few months ago when I bought the homing kit.
I’m realizing as I work through this that CM doesn’t really know what’s set in grbl unless it makes the changes itself. I guess I was assuming a little more 2-way coordination between the controller and the program. Maybe that assumption is not totally accurate, but I was able to set a zero point through CM as I have been doing since before having the homing switches, and it was stored and persisted through multiple resets. I did switch to G55 when trying to send the commands directly, so I suspect that it’s storing the values set in the GUI to that WCS. I still need to try switching to another wcs, setting a new zero point, and switching back and forth between the two. But anyway, I finally was able to get one job going at least.
Hi there. I just got my 3xxl assembled and started carbide motion. Went to mid and did three $22=1. Just sits there and doesn’t do anything. Any ideas.
