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.
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.
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.
Machine Initialization…nothing new here except not probing
Zeroing process…new steps to probe bit after zeroing regardless of whether that was with a BitZero or manual. Process is the same after zeroing is complete.
Job start process…difference here is that after probing bit length CM compares it against the stored bit length for validation and acts accordingly if things are out of sync.
Mid job zeroing process…difference here is that a new Z’ is persisted along with WZ being updated as per tool length delta.
A happy path workflow where the user does what he is supposed to. Followed by one where he does not. CM is able to detect that he has not and prevents the job from being ran until the situation is corrected. This is not something the current workflow can detect and would allow the user to shoot themselves in the foot.
NOTE: All this is predicated on there being a method to store a Z’, either in a previously unused grbl setting or in a file in CM.
Some of my 3D carves on my Carvewright have been 16+ hours, so this would be a great feature to add.
I don’t find CM intrusive.
I have to assume there are people smarter then me that have the knowledge and history / experience to figure out the workflow. I believe CM has certain goals to meet to provide a good don’t get yourself in trouble workflow for hobby cnc machines and new users. There are other G code senders available that may be considered more advanced and have a more open workflow. And we are free to try them.
I appreciated the workflow when I first started this hobby.
My wishlist item re air passes.
Currently I do an air pass at say, 1mm above the work as a sanity check (saved my bacon this morning). Then I have to hit pause and then stop and wait until the machine initialises to 0,0. Then I go to my work piece and set the new Z height and continue.
I would like to have Air Pass as an option when I go to run my toolpaths, so I can say Yes, or No and continue.
No need to disable/reenable bitsetter for large batches. Just save the carbide file as gcode, open and remove m6 command, save and run that file instead of carbide file.
Good idea. I haven’t gotten into manual edits of the gcode yet. I do need to learn the basic commands though.
Wow, Carbide 3D, do I get a cookie for the post with the largest response? Love to see all the enthusiasm guys. I’ll pass on a couple of tips that I learned recently (I know, wrong post, but this post has gotten pretty loose). The VFD with a 1.5"dia surfacing carbide 4 insert cutter should not be set to take a .070" cut in Acacia, stalled it. On Amz, you can get a box of 3 different size Acacia cutting boards for $40; they make great project matl for plaques, etc.
Cough. Seems I had good ideas, perhaps not original, after all.
Sounds like we are speeding up the process, I love it!! The only other feature I would like to have is a process repeat but maybe this will shorten run times. Will suggested a way to incorporate it in the code, it works, but maybe something a bit easier to implement would be nice.
In an unrelated topic: Carbide Create needs a Command+W in the Edit menu to close a window. Every Mac app worth its salt has this. Additionally, how difficult would it be to have Carbide Create remain “Open” or running when a window is closed? The application currently “Quits” when a window is closed and does not seem to support two open files at the same time. We should be able to have two instances or files open at the same time. That would make it easy to copy and paste elements between files.
Just a thought. Thanks.
That isn’t an uncommon problem with apps for OSX. One example that quickly comes to mind is the Eclipse IDE software. A simple cheat for this is to make a copy of the app in your Applications folder, giving it a different name. You can the open each individually. There are probably cases where this doesn’t work but it has been my go to when in needed.
Hmm… interesting. I’ll give that a try.
I tried what you suggested. For a minute I thought it would work. The copy of Carbide Create did open in a separate window on my Macintosh. However, I could not copy from one instance and paste into the second one. I could only paste into the instance from which the copy was made.
I was very surprised that both copies of the program opened at once. I never thought to try that. Great experiment. I still wish they would add the Command+W to the Edit menu. Carbide Create should quit when I tell it to, not when I simply close a window.
Sigh… it’s on my wish list.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.