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.
It would be great if you could jog while paused (without having to stop the job) and have then have two options to continue:
- Continue in place: The job continues where it left off, from the new position of the gantry
- Return to paused location: The gantry will “home” back to the XYZ that it was in when Pause was pressed and then resume the job
This would allow us to:
- Make a slight alignment adjustment on the fly, without having to rezero a machine between runs
- Raise/Lower/Move the gantry out of the way to be able to gain access to the piece beneath, then resume the job
- Gary
3 Likes
We do need to be careful on what we think CM should be able to do. We must remember that CM is “Free” for starters. Also, these CNC’s are not production $150,000 CNC machines that some of us have operated or have seen in operation. They are hobby machines, all be it, on the high end of that scale. The production 3 axis CNC mills I have run, can’t even do what you asked for. As a whole, these Shapeoko machines are crazy accurate and are very capable. There is a bit of added rigor on the part of Carbide 3D to insure safety and avoid catastrophic failures. Someone posting a video of a failure is bad for business and can also injure someone.
6 Likes
No it doesn’t. It needs to know how to adjust G54 before job run. Probing on initialization makes an assumption (since it sounds like nothing related to bit length is persisted) that the bit currently in the chuck had been accounted for in the stored G54. If that assumption is false the probing accomplishes nothing and gives a false sense of correctness. If that assumption is true the probing is superfluous because the length of the bit in the chuck was already accounted for in the G54.
Unless there is more than meets the eye going on here, or there is a use case I am not considering, things can be better and folks seem to want to say “this is the way it has to be” without providing concrete reasoning as to why it has to be. I understand that it is the way things are with the current state of the current capabilities.
In software is is common to build out some baseline functionality, find small flaws over time, and bolt on additional parts to correct those flaws. Sometimes it is necessary to revisit the problem with a clean slate and a better understanding of the problem space. This can often allow you to arrive at a simpler and/or more robust solution to the problem.
It is already trying to protect the user from shooting themselves in the foot. I am not asking it to do more, functionally, than it is already attempting to do. But I am suggesting it takes a different approach than it currently is…one that can account for more scenarios and catch more user errors than the current implementation.
On a scale from 1-10 for software complexity, solving this right is about a 1. Let’s not pretend like this machine vision or natural language processing.
I don’t really see the issue.
On initialization it gets the position of the bit currently in the router or whatever you put in at that point. I usually put a 1/4 steel pin in.
Then I use Bitzero to probe using that pin. Now it knows where zero on the material relative to that pin is. Then I start a job and load the first tool when prompted. At that point bitsetter measures the tool and calculates the Z offset required such that the tip of that tool will be at the material zero.
I dont feel it is intrusive and I dont know how else I would want it done.
1 Like
Concrete scenario: (1) you are starting work off where you left off yesterday. Neither the bit or material has changed since your last run. You initialize the machine and it prompts you to insert a bit and then measures its length. This is unnecessary because neither your bit nor material has changed. Next you want to rapid to job zero to double check that xy was not lost since yesterday. You are greeted with a dialog asking if you want to measure tool length and a warning dialog after saying no. You then rapid to xy and manually jog Z a little to make sure Z height still seems legit. You then click the run tab and you are greeted with a dialog warning you that you did not zero and to proceed with caution. You then select the file to run and click the run button. You are then promoted to insert a bit and then but length is measured again. All in all that is 2 prompts to insert a bit, 2 probes, a prompt to probe bit length, and a warning dialog about not having probed bit length.
Now imagine a scenario where the system can store a Z’ that was collected by measuring bit length after last zeroing……
(2) You power up the machine and initialize. The machine does NOT prompt you to insert a bit note measures length. You go to jog to verify existing zeros and it does NOT suggest that you measure tool and does NOT warn you about changing bits without measuring tool length. You then click to run the job after selecting file. It DOES prompt you to insert tool, but since you already have your bit in you dismiss. It then DOES measure tool length, but since it has a stored Z’ the current measured tool length CM does the math and verifies your current bit length matches that. It proceeds to prompt you to turn on your router and all is well….1 prompt to insert bit, 1 probe of bit length.
(3) ….But wait, you forgot that you did swap out the bit to a newer one as the one used for the last job was getting dull. So after you click run and you are prompted to insert a bit, which again you acknowledge, it goes and measures tool length. This time CM realizes that your current Z’ does not match that collected at the time last zeroing and it aborts the job and advises you to rezero Z with your new bit. You go correct that and after clicking “zero z” it proceeds to measure tool length and saves Z’. You got to run the job again, you are promoted to to insert bit, it measures bit length and confirms it is in line with Z’ and things proceed happily. 2 prompts to insert bit, 2 probes, and no warnings or prompts with regards to jogging.
(4) You starting a new job with different stock and bit than yesterday. You start up the machine and it homes. It does not prompt you to enter a bit not measures bit length. You go to jog to either manually zero or probe, either way you have to do some jogging. It doesn’t request that you “change tool” and does not nag you about not having done so. You go and zero, after having put the rod in the chuck and the length of the rod is probed and stored in Z’. You go to start the job your are promoted to insert your bit and the length of that bit is measured and discovered to be different than Z’. The job aborts and the system advises you to zero Z with the bit you currently have in the chuck.
Scenarios (3) and (4) require about the same amount of user interactions as (1). However, it guarantees that the current bit length was taken into account in G54 while making scenario (2) a whole lot more efficient than. It moves to a verification model for ensuring G54 is right versus a hope-the-user-followed-the-expected-workflow verification model.
Personally I don’t find it that intrusive. You are talking about a few seconds when initializing the machine. In the grand scheme of things that doesn’t matter to me.
In fact, yesterday I cut 22 plaques all with the same bit and the same compositions. I let it remeasure between each job even though that wasted 30 seconds because I did not want to disable and then re-enable the bitsetter later.
When I manually jog I happily disregard the nag messages. Some people may like them. There was a thread yesterday where a guy was asking for an additional bag screen to remind him to set zero.
To each his own. Maybe try gSender and see if it behaves a way that is more to your liking.
6 Likes
Zn = Zn-1 - Ln-1 + Ln
You’re right that it doesn’t need to adjust the current Z position for the tool, but what it needs to know is Ln-1 for the next time you want to change the tool. The only way to know that is to assume (and tell people to make the assumption true or suffer the consequences) that the same tool is still loaded and probe the length of it.
In my scenarios described above, since there is a stored Z’ (whether from the bit the machine was zeroed with or adjusted since then by probing) the software can always validate, and not have to make any assumptions, that the measure bit properly relates to the work zero.
Let me restate the concept since I seem to have poorly articulated it. Z’ is the machine coordinate Z value for which the bit was last measured. It would be first set after a bit length probing cycle after a zeroing. Each subsequent bit length measuring would adjust this value at the same time the work zero Z is updated (either during probes in a multi tool project or a manual rezeroing of the machine). At job start time the inserted bit is measured and the new Z’ value compared to the stored Z’ value, if they differ the software would force your to rezero because things have gotten out of sync and bit length would be measured after you rezeroed.