Most of my projects include cutting all the way through material AND cutting logos and dados etc. into the same side of the same material. These machines are computers, why can’t they “know” both of these Zeros? That would just make so much sense and would keep our spoil boards going for a really long time.
Not sure if this is the place for this question. Please let me know if I should post this somewhere else or if there is already a way to do this that doesn’t involve creating and running two programs to achieve this goal.
Peace
Technically CC/CM do know. When in setup you set the material height. You set top or bottom of material. So by setting the material height accurately the software knows where the top is and when to stop cutting at the bottom. I use bottom about 90% of the time and that saves my spoilboard from being cut up. I only use top of material if I will not being cutting through the material. So accurately setting the material thickness is extremely important. If you use bottom and do not accurately measure the material thickness the first cuts may be deeper than you intended. If just a few thousands off likely wont hurt anything but setting the material actual thickness is important.
When I am making a project I know about what material I will use. So I may use .75" for the planning but before I cut I measure the material on the spoilboard and set that in CC. Save the file and begin the cut. Unless you are planning your own material most material is a nominal thickness and usually is not exactly as advertised. Plywood is a perfect example. Advertised at .75" but is more likely to be .7185". That is why most router bit manufacturers make smaller router bits for cutting plywood dados.
1 Like
Having multiple Z Zeros in a single file would be a recipe for mass confusion. Since there are already two different ways to handle the problem, I can’t see how adding the capability to CC is a good usage of dev resources.
- You can use two files, one for each Z Zero
- You can accurately measure the thickness of your stock, and use either Z Zero.
2 Likes
Thanks for the deeper explanation OF the problem. I have been using the Shapeoko for several years now and am painfully aware of the technical details of this situation. I may have phrase it badly, I am looking for a solution TO the problem.
Yes, I know I can use two files, that is part of what I stated. As long as the recipe includes toolpaths that can be tied to the different zeros (something you can already do, just in two different programs) I can’t see how that would not be helpful, easy, and much more efficient than having to create and run two separate programs for each piece(s). Also, I don’t know what kind of material you use, but I carve logos at .02" depth which can exceed the nominal difference in thickness of the materials I use (solid wood and plywood). So yes, for that I MUST zero from the top of the material. But then the cutout, now based upon that material thickness that is NOT perfect, will sometimes eat into the spoil board. So one program that could incorporate BOTH zeros would, in fact, be quite helpful for many of us.
Maybe this is not a place to ask questions about making programs better??
2 Likes
I would argue that if you need logos at a consistent depth, and the nominal material thickness can vary enough that you can’t use stock bottom for everything, that means you probably ought to be surfacing your project to bring it to a known thickness. That way you guarantee your engravings are to an exact depth, you know for sure your part is truly flat, and you can then use a single zero.
But also, when you set a zero on top of your project, you’re not dynamically compensating for the unevenness of your stock. You’re just picking an arbitrarily average point that might be more accurate than using calipers near the edge. You can bake that thickness into your carbide create file instead. So what you’d do is:
Set your Z-zero exactly on the MDF, the position readout should be Z=0. Then manually jog to where you would normally set your zero on top of your stock (wiggle a piece of paper under your spindle until it catches). Look at the coordinates on the position readout, plug that into Carbide Create as the stock thickness. Save your toolpaths and run it.
5 Likes
The thickness issue is something i’ve dealt with and my solution has been to zero off the bottom and start the process with a flattening pass to get a known thickness and go from there. If you’re using plywood, would that be an option? even just a really minimal pass might be enough to get it to a known height that would allow everything else to be consistent.
1 Like
Wow. Ok, I use solid wood and plywood. I don’t use mdf or metal. The variation in thickness, at best, is not less than .02". I use the bit setter AND the bit zero. I very rarely have a problem with the logos when I use the top of the material as the zero. From the bottom as zero, not so good.
This really seems like everyone assumes I don’t know what I am doing, and if I did, the problem would go away. It will not. I have been working with this machine and this program, quite successfully, for many years now.
I was asking about a solution to an existing problem. One that would be solved via the software being able to use 2 Zeros.
I was not asking about how to do what I, quite clearly explained, I was already doing.
I envisioned a world where I could create one program that would use two Zeros INSTEAD of two programs each with a different zero. I guess I dream too big for this world.
2 Likes
We’re not assuming you don’t know what you’re doing. I do think what you are proposing would be interesting. Cool, even. But also fraught with potential for disaster and misunderstanding, and therefore unlikely to be implemented as-proposed. We’re trying to provide solutions that are as fool-proof and easy as possible given how the software works today. And I would argue (without trying to be difficult) that [zeroing at the table once + measuring the stock top, plugging a number into Carbide Create (and having the toolpaths update automatically if you use the variable “t” in your settings), then running that one program], is just as fast as going through the zeroing process twice to establish two different work coordinate systems, and also configuring your program to work with two work coordinate systems. And possibly one less place to fat-finger something and ruin a project.
1 Like
Would it take some learning to implement? Yes. But so did building this machine and this program and this company. And each of us (well, I did anyway) had to learn a lot to use this machine and the software. Many, many, many features have been added since I first starting using this software. Some of which changed the entire way I work with the machine. So, yeah, all change comes with the possibility of failure. I don’t think that mode of thinking is what got us where we are today.
Again, maybe I’m a dreamer, but I’m not the only one. Maybe some day you will join us and we can live as one.
It was just a question. P.S. Message to all us us two years in the future when this feature is implemented, your welcome. 
1 Like
The obvious generalization to “Two different Z Zeros” is just “Use multiple Work Co-ordinate Systems in a single program”. Looks like GRBL supports WCS G54->G59, so that hurdle at least is cleared.
The problem then becomes the workflow. CM right now has no concept of multiple WCS, so that would have to be added. Then there’s setting multiple WCS, with some way of communicating to the user what WCS is in use and what WCS has been set.
Older versions of CM have no idea about this, so if a CC program does use this feature, you need a way to have older versions of CM reject the program. Of course, those programs are already in existence, so you have to work with the capabilities they have already - they may not have a graceful way to tell the user that this particular CM program is using a feature they can’t handle.
There’s also the problem that in CC, there is some expectation of how the co-ordinate systems are related - for example, that only Z Zero has changed, and what system represents top-of-stock and bottom-of-stock. How do you communicate those expectations to CM, and from there to the user?
1 Like
As Michael mentions, GRBL does support multiple fixture offsets. CC does not.
I haven’t tried it, so no idea what CM does with it.
Many other CAD/CAM systems do support it. But they also cost more.
So, we’re either stuck using 2 files, changing the Zero height from Top to Bottom and posting paths out separately, or what I do is before cutting the profile path jog the tool down to the spoilboard, about 0.001" above it, and typing in the -Z value of my stock thickness.
If I’m profiling the job, I will also frequently add a layer of 2-way tape to the bottom to lift the material another 0.010", giving me a little space between the stock & table.
Multiple MCS (Machine Coordinate Systems) would be cool. They could be applied per toolpath, or per toolpath group. But the workarounds are reasonable & keep the software & workflow lean & simple.
1 Like
A simple toggle for the tool path in the pop up menu just like the ones that are already there. Seems simple enough on the user side. I have no idea about the code side.
You just described the CC side. Now what about CM, where all the hard parts are?
1 Like
Isn’t the saying, “Hard is what makes it worthwhile doing?” or something like that?
1 Like
I’m pretty certain CM only supports one fixture offset (G54)
To set up another offset, you would need to type in the G10 command manually, or store it in a macro/ user action.
The mystery is what does CM do when it sees a G55?
If it passes it through, then GRBL can handle it, as long as you’ve set the zero for G55.
Unless this is some pretty heavy production work, it’s much easier to just reset zero. (only using G54), or just check the spoilboard on cut through toolpaths.
Well, on the CM side, as a user, it just runs the program crated in CC. So, if this were a feature, I would assume the code would be there to pass on the info. Again, I am just a user, I have no idea about code in general or specifically with regard to either of these programs.
Yeah, that is what I do and the vast majority of the time it works out pretty well. I was just imagining a world where the machines are a little smarter than they are now.
No, CM does way more than that. Before running the program, you need to set up the workspace so the program knows where to run. That means setting up your zeros, and if you want multiple zeros, then that means CM needs to handle setting up multiple zeros. They aren’t independent zeros, like you might use for running the same program on multiple workpieces. The zeros have very specific relationships to each other in CC, and those relationships have to be preserved in CM.
Now, express all those constraints in GCode.
Well, actually I have to set the zeros via the bit zero. Ok the machine helps.
I don’t write or read code, so challenge not accepted.
But to hazard a guess, in CC each toolpath would be tethered to one of two distinct zeros. Then, when run in CM each tool path would que off the pertinent zero, both of which would be set as we set the singular one now. I am a simple man, and this seems simple. But to emphasize this again, I don’t code, so maybe it is far beyond these simple computers that run the world to pull off such a feat.