Thanks, Will, but I’m very aware of this possibility, and make every effort not to choose the wrong option.
I confess to having done this once, but realised before probing, so just cancelled it and started again.
Good thought, though.
Thanks, Will, but I’m very aware of this possibility, and make every effort not to choose the wrong option.
I confess to having done this once, but realised before probing, so just cancelled it and started again.
Good thought, though.
Is 12.53mm the thickness of that material and “Z” 0 would be at the stock bottom/table surface?
I do not have a bitsetter, but could it be that in this instance you had the “Z” zero set as the bottom/table surface?
edit, n/m
I downloaded your file and see that the Z zero is set at the “Top” on 1.00" stock…as it should be
I appreciate all the help and guidance offered by everyone for this very frustrating, random event, that I can’t seem to get to the bottom of, but I’m also worried things may be going ‘off track’ a little, so I’m going to summarise everything as best I can, with what I know as fact, with a conclusion that may be considered controversial.
Things I know:
Conclusions:
As all mechanical parts appear to be sound and the steps from starting the machine to running the project are considered to be correct, then either the BitSetter is mechanically changing the Z zero set by the BitZero, or there is a flaw in the software causing that effect, but it is not user error.
Therefore, would you (@robgrz, @Jorge, @Julien, @WillAdams, et al) please consider the user might not be at fault and the issue might be with the software at your end?
Thank you all!
Hi Peter,
Believe it or not, I don’t think anyone has any vested interest in defending CM at all cost, there have been many instances in the past when someone came up with evidence of a CM bug, and it was acknowledged and fixed. The random aspect of the failure makes it both irritating for you and almost impossible for any developer to investigate (where would they start ?). What we have established is that something is different in your setup/workflow/project/hardware, producing this random problem when most other folks do not see it (you would argue that several people have reported similar issues, but most of those long threads ended up being user errors, which is not the case here)
I like treasure hunts, so I’ll actually be happy and relieved if in the end we do find a CM bug. But for that, we will need to dig deeper and, I’m afraid, you will need document those failure cases in excruciating details, including tool stickout at each step as I mentioned in my previous post. Or identify a repeatable way to make the BitSetter fail, but I don’t believe this will happen.
The BitSetter does alter the Z zero reference set by the BitZero, always, on purpose. We “just” need to understand why it does it with a wrong offset/compensation value, apparently randomly.
Does your BitSetter “stick” when you push it manually ? It could be interesting to probe the same tool repeatedly, and check (in the logs) what Z value it triggered at, to detect whether from time to time it comes up with an outlier value for any reason. By the way I lost track of whether you have interacted with support on this problem and where things ended up with them ?
Well, it now occurs to me that you should either change versions of CM or change to another sender.
That’s the only way you’ll eliminate the software possibility.
Yes, we’re perfectly willing to accept that their are bugs in our software — we’ve fixed a lot of them, and we usually do so based on bug reports which are repeatable at our end.
From: https://wiki.shapeoko.com/index.php/FAQ#Troubleshooting_Concepts
To eliminate the software, please check it in a 3rd party previewer — list at: https://wiki.shapeoko.com/index.php/Previewing_G-Code
Verify that you are using up-to-date software versions including the firmware (Grbl 0.9 originally, currently 1.1 and that the versions match, Carbide Motion 3 with Grbl 0.9, CM4 or later with Grbl 1.1).
Review that the machine is properly assembled according to the assembly instructions and that everything checks out per the Machine Operating Checklist: Machine operating checklist
The software works by:
The machine then cuts based on:
For electronic accessories, check the connectors and the wiring along the entire length and that they are properly configured and enabled.
To extend on the above, we need to work up some technique for verifying the functionality of the BitZero and BitSetter.
For the former, it should be a straightforward matter of after probing, use the jog controls to move the machine around to verify that the origin was set as desired relative to the stock.
The latter can be a bit trickier, since if one is running tool changes in a G-Code file, the machine still has control — please try breaking up a test file such as:
and export each tool separately, then do a tool change in-between each file.
Let us know what you find out and we’ll do our best to sort things out.
To review, the expectations are:
I would suggest breaking things down and testing incrementally:
Not being picky, but please clarify this. Especially the “always” part… does this mean even (potentially) after the probe and during cutting?
@NewToThis
Have you tried running with all the peripherals disconnected?
(fwiw…you may have mentioned this earlier but I missed it)
I meant “systematically upon probing”. It does not interfere later (during the cut), that’s guaranteed by GRBL behavior (which ignores the probe signal input unless explicitly requested, and that happens only during probing through a G38.x command). Technically one could also imagine that CM would erroneously sends a command to change zeroes during a cut (very unlikely if you ask me, but let’s keep an open mind). A dump of the log window would settle the matter.
Thanks, Will. I appreciate the sentiment and information provided, but seeing this has set my teeth on edge. Most (I haven’t read it all, but I will) revisits all the points raised over the previous replies, so may not be useful, specifically your reference to using a 3rd party viewer. If it works the first time, why didn’t it the second time, following the same procedures?
As I said, I’ll read what you’ve copied and pasted, but it will take a while.
I believe you, but it’s a struggle when I’m confident I’ve done everything I can to make sure I stick with the guidance - to the point of writing and pinning up a checklist - for it to go wrong at a random moment.
Maybe permanently enabling the log would help - at least temporarily? Maybe an option in Settings to keep it enabled (disabled by default) would be a good idea, then we can keep it that way until a problem occurs. Of course the log for a particular session doesn’t need to be saved after a successful session, but saved manually if the machine ‘misbehaves’ (Which would also obviate any performance issues, as identified by Will).
No it doesn’t, but the BitSetter button did come unscrewed from the mechanism and I had to screw it back in with a drop of thread glue.
Not yet, other than for flattening boards with a fly cutter, which went well. I’m convinced this is an issue between the software, and/or the BitZero, and/or the BitSetter, so when I next run a project, I’ll probably dispense with the BitZero and see how that goes.
My thinking too. I have looked at some other senders, but I want to retain the use of the BitSetter, BitRunner and BitZero (otherwise they would have been be a waste of money), and I haven’t really found something I’m confident to play with, yet.
Please provide a .c2d file, generated G-Code, step-by-step notes on how you are securing your stock and setting zero relative to it and managing all tool changes and notes and documentation on how a workflow which should work, results in an incorrect positioning relative to the stock which is repeatable — with that, we can look into this as a problem with the software.
If things aren’t repeatable, then it is likely some electro-mechanical aspect of the machine which is having a problem — we need for you to work with us on support to work with us so we can determine what is causing the problem and how to address it. Send an e-mail to support@carbide3d.com describing the difficulties you are having and we’ll do our best to sort this out with you.
I know you mean well, Will. But this is clearly copy-and-paste text from 100 other support responses you make, and to be honest it sounds a little patronising after two huge threads detailing pretty much all of this. Peter has done some of these things already. We have his c2d, the gocde fine, pictures of his stock, how its secured, what he is doing. (plus, how the stock secured is irrelevant for nearly all of the occasions when you ask for it.)
And when I’ve run his files, I don’t get the results which he notes, so it’s not repeatable, so we need for him to either increase the detail of the information which he is providing so that it is repeatable, or work with us via an e-mail to support@carbide3d.com so that we can determine what is wrong with the machine if it’s not the software and not user error.
I get that. But perhaps those lines from your support template should be tailored for the specific situation. Otherwise, it comes across as robotic and implies you haven’t read the thread, which I know you have.
And when I run my files I don’t get an error - until I do. It’s random, @WillAdams, and by definition not repeatable.
Jeez.
Please provide a list of all the ways that your files have been out to support@carbide3d.com and we’ll do our best to work out with you how to resolve this.
Peter in your recap above if I read correctly you design on the Mac and run CM on a Windows machine. I know that it may be a stretch since Windows and Mac play well together now that it may be just something in transalation between the two. Have you tried doing both design and running from the Mac and design and running from the PC? I have seen weird things happen cross platform before. Also running all the latest software may get rid of this bug.
I’m not sure of that would cause a random event, but I’ve got my MS Windows machine running in MS Remote Desktop on my Mac, so trying it wouldn’t be a problem.
I’ll give it a go, thank you.
And so the circle closes.
You no longer inspire me, @WillAdams, and my future with Shapeoko is dwindling fast.
Please write in to support@carbide3d.com with your suggestion for how this should be researched and resolved.