Interesting, i will test the overlap boundary to see how it works, i worry about a noticeable glitch at the transition is almost inevitable. I have issues with overlapping svg images all the time
For the 3D roughing it shouldn’t be an issue — depending on the nature of the 3D toolpath and where it is, it might be visible, depending on the material.
It should be possible to make vector geometry seamless — post a file you’re having this trouble with?
3d roughing isn’t a problem, that is fast. It’s the 3d finish is the long run time with small cutters
Utilizing boundary geometry with 3D finishing works - I have been playing with it a lot recently trying to speed up a carving.
After having multiple random disconnects while machining parts the past couple of days, I feel that’s a major cop out on Carbide’s response of “You should split up your file”.
Needless to say, my friends and coworkers have heard me sing the praises of the failures of the electronical bits of this machine.
Electrical disconnects are a separate issue, see:
If you continue to have difficulties, let us know at support@carbide3d.com and we will do our best to work through them with you.
Must a 3d finish be preceeded by a 3d rough or can it stand alone?
Regarding grounding, I am definitely a fan of elect grounds. Not only is my Shapeoko 5 grounded but my dust cyclone is grounded top and bottom to the cnc cart and I run 3 separate elect circuits, 1 for cnc control, 1 for vac and 1 for the VFD spindle controller. I have had zero electrical issues.
A 3D Roughing pass must precede any 3D finishing passes.
If you do successive 3D finishing passes, it’s best to not skip sizes, so something like:
- 3D Rough w/ 1/4" ball-nose
- 3D Finish w/ 1/8" ball-nose
- (second) 3D Finish w/ 1/16" ball-nose
Separate issue, but related to the need for a “Run from here” feature.
As for the disconnect issues, I point the finger at Y’alls electronic design. (Yes, I know YOU don’t have anything to do with that) .
I have no disconnect issues with the Sieg X2 mill I converted to CNC, utilizing a pc running Mach3, a PMDX break outboard, Geckodrives, and just recently added a Smoothstepper when I had to replace the PC. Both machines are in my basement, with the humidity around 45%. So, your clip and paste response doesn’t apply.
Perhaps Carbide3D should look into using a network connection like Warp9’s Smoothstepper instead of a USB.
1 Like
Every revision of the electronics has added more and more isolation. Along the way we’ve found that the vast majority of the problems are from static on the vacuum hose. As long as you make an effort to ground the vacuum hose (and even wrapping the hose with wire seems to work much of the time), the current Shapeoko 4 / Pro electronics have very few problems, and the Shapeoko 5 electronics have almost none.
If you do have a grounded hose, and have a persistent problem with a current machine, shoot an email to support- Jorge might have ideas.
5 Likes
I would argue that if the relief is shallow, and a rough cut would not remove much material, then you can skip the roughing. I use tapered ball mills that will dig a good 1/4" even in hardwood. And if the stepover is really small (and it usually is for a good finish), you’re not over torquing the spindle.
1 Like
Tod, understood; I haven’t tried tapered mills yet. Although, in my experience, the roughing pass is usually only a few minutes, so, not a problem.
1 Like
@robgrz, question, I am having trouble understanding the need for bit length measuring on initialization. I know work zeros are persisted across power cycles and that, at startup, the Z component of that (call it Zo) could have been determined with a bit/rod that is different than what is currently in the collet.
Measuring the bit at initialization would determine a Z at which the current bit touches the BitSetter (call it Ln). Is there a stored value corresponding to Ln (call it Lo)? That would allow calculation of new work zero height (call it Zn). Is that what is going on?
Zo = stock top + Lo
Zn = stock top + Ln = (Zo - Lo) + Ln = Zo - Lo + Ln
What really helped me to understand what is happening is that when you set the Z zero position, you are setting the position of the Z axis. That is, the position of the router mount, not the position of the end of the end mill. But what you want, and what the software needs to take care of for you, is to make Z zero be where the tip of the end mill is positioned.
When you initialize, the sender (Carbide Motion or other) assumes that you haven’t changed the end mill since you set the zero position and it has to probe the current tip of the end mill to know the offset from the Z zero to the end mill.
I can’t speak to how CM handles the measurement from the bitsetter, but in my macro (I run CNCjs and have to implement this logic in a macro), I maintain the last probed length in memory and then I change the actual Z zero position by the delta between the tool lengths. This keeps the current Z zero (position of the router) such that the tip of the end mill stays at the same height when I change tools. Using your notion (Zi is the actual Z zero of the ith tool and Li is the length of the tool stickout):
Zn = Zn-1 - Ln-1 + Ln
(edit to add a link to the my macro if it helps you: https://github.com/crpalmer/shapeoko/blob/master/cncjs/Prb_Tool.txt)
Right, in the end all that matters is that the Z value in G54 (or is it 52/92) is right with respect to the currently inserted bit at the start of the job.
For that to happen either the machine will have had to been zeroed with the currently inserted bit or probing have happened after every bit change since being zeroed and the described math having taken place.
I still am not understanding why that means it has to happen on initialization. Another, potentially less intrusive, workflow could be that bit length is measured immediately after zeroing (you click something in the UI whichever method you use) after zeroing, and then bit length is again measured after the tool insertion prompt when starting a job. That would satisfy the conditions of paragraph 2 without any unnecessary intermediate probings and prompts.
As it stands, I believe the issues people have with using the BitSetter is that there are so many superfluous interactions spawning from its activation that it becomes the same kind of cognitive noise as that benign check engine light on your dash that you know doesn’t really require you attention. Noise that desensitized you to the point that you do not notice that serious check engine light that popped up a week ago.
The reason that you need to probe on initialization is that the Z zero (position of the router) is a persistent value that is maintained even when the machine is turned off. The probed length of the tool is not persistent and must be recomputed after the machine has turned off (disconnected).
1 Like
I understand that there are probably no persistent gcode parameters that could be used to store that extra tidbit of info (actually there is probably something that could be coerced into working for that). But whatever gcode sender you are using certainty has some persistent storage that could be used for that purpose.
Storing that seems to be the missing piece that could open a lot of doors to a simpler and more full proof workflow.
Re: Bitsetter chk on initialization
Unless you left the last tool used in the collet, untouched, the machine needs to reference whatever tool or probe you plan to use first after startup. That’s really all that’s happening; don’t over-complicate it.
4 Likes
I don’t think I am overcomplicating it. I think the currently workflow is overly intrusive while not being as full proof as it tries to be by being so intrusive.