After seeing the touch control interface come out it made me realize you guys are always working on new stufff quietly behind the scenes. So I thought I would try to plant an idea in your collective heads. How about a tool length sensor? Not something to set the initial z height but something to help with tool changes. Much like the bitsetter made by shapeoko. Is it necessary? No. But it automates something that takes quite a bit of time when you have many tool changes. And in a high work environment I can be elsewhere doing other things in the shop during that time. Just a suggestion.
machine a pocket in your spoilboard where you can park your XYZ Probe Plus in when not in use. Store XY position above it as a G28/G30 or machine coordinates coded into the macro. Create a macro to move to above the probe plate, and do the tool probe No need for anything new product, just some time to set it up.
oooooo and the macro can pop up the z probe wizard too, right? Or can you not mix gcode and javacript in a single macro?
You can certainly add some sendGcode("G***") action inside the js macro It may be a while before I have time to create the macro, but I am certainly around to assist if anyone wants to take a knack at it. How is TLO supposed to work in GRBL? · Issue #402 · gnea/grbl would be helpful (using TLO instead of rezeroing Z - zero stock once with first tool, rest of tools set with TLO instead)
Peter, thanks for the reply but... you could say the same about most functionality within the Openbuilds control software. But, for some reason you include buttons to do certain things and not others. I assume economic reasons dictate a large part of what you include and what you don’t. I was hoping by asking in a public forum I could entice other’s to voice their desire for such functionality and therefore give you an economic reason to include. By your answer I assume you have had this conversation amongst yourselves and decided this feature would have little to no positive effect on sales. Ah, well One can dream.
Contrary. The whole point behind all the scriptable macro work was to provide a platform to make feature development more open and easier - with the hard, experimental work done, so much easier to make a case for implementing it for everyone. In particular as tool length setting has long been on the todo: Toolchanges · Issue #26 · OpenBuilds/OpenBuilds-CONTROL Building out the feature in Macros first gets it polished up, gets valuable input like David's below, etc - before rolling it out to everyone. If we didnt want to develop the feature, i certainty wouldnt be posting advice above on how to make it happen (; Adding software features is FREE so yeah, no need for a new product, just adding another routine to use with your existing XYZ probe. Sure we could sell everyone a switch (of dubious repeatability) in a box, but this way everyone gets the new features for free in a future update. Much better if you ask us
The problem with tool length offsets is that they can be quite dangerous. The first tool could be the 'standard', and all future tools are either shorter or longer. If they are shorter and the offset gets set incorrectly you are unlikely to have a crash, but if they are longer a crash becomes quite likely at the slightest hint of a stuffed offset. A possibly better way to do it is to have a "tool 0" which is longer than all tools, and Z0 is set with this tool, no offset. Now all the real tools are shorter and the offset is always negative, giving a margin of safety and resilience. You also have to consider your part zero settings, if you are using a tool sensor that is not on top of the material, then you do need to remember to set the correct origin in the CAM, ALWAYS. Mixing 'Z0 on top' and 'Z0 on bottom' will inevitably lead to a crash. Professionals, especially on 5 axis machines, use a fixed 0,0,0 that is at the center of the vice rotation for all jobs, to prevent crashes that can get expensive. All that to point out that the software cannot solve the entire chain of command, the humans involved need to follow the correct procedures as well, for such a system to work properly. (I get quite excited when someone finds a genuine bug in software I develop, as opposed to a run-of-the-mill 'garbage in = garbage out' user error.)
yes and no. yes in that it will work (except for limit crashes), no in that you now have the maximum travel to probe for every tool, every time. This will probably take more time than you are happy with, leading to shortcuts, leading to crashes.
Remember we can add GUIs - so we can guide a user step-by-step through the toolchange Use loads file with toolchanges and clicks Play. First tool runs, no TLO active. Just zeroed as we always have - Come to first toolchange: CONTROL takes charge again: We go to saved XY probe location in machine coordinates. Probe the Z axis & store the information (T1) - Go to a tool change location and wait for tool change & confirmation via UI - Return to probe location. Probe the Z axis again (T2) & calculate the difference from the previous tool (T1) Apply a tool length offset using G43 or even calculate difference and adjust Z-Zero directly with G10s - Prompt user to remove magnet, continue job on resume We can add a DRO field while a TLO is active too
do a tool change with Z all the way up. go to probe position, Z all the way up. probe from tool0 Z, long way down, takes time. if we can rapid to a lower Z height from which to probe, it will take less time. also keep in mind that probe speed makes a difference to the probe length found. probe at high speed will find a 'shorter tool' because of the overshoot during deceleration.
I have often wondered why a tool length sensor is necessary with grbl since we have to manually change tools anyways. A tool length sensor is in a fixed location which is fine if everything is automated and you are not around. If I an cutting something large with my CNC, I may be 1000mm away from that fixed position when Estlcam tells me to change tools. Estlcam just raises to a safe height and pauses at that spot. I turn the router off (that is important), change the tool, and if I am smart I remember to re-zero the Z for that tool as David suggested - jog down close to the z probe then probe and reset my Z. I was going to install one, and then realized it would make tool changes take a lot longer. I could see it being valuable for 3D carving, but I could just zero on the spoil board for everything with the z probe and avoid the long travel distances. On my lathe, I have it in a set position which is on the tailstock because it is flat and I know the height of that surface above the rotational axis.
I was saying maybe adding another field below XYZ, for TL so you can see by how much the tool is set.
Would it be possible to wire in a 5v proximity sensor to the probe input on the blackbox? I'm trying to sort out a way to make TLO setting quicker and safer. My thinking is that I could write a probing routing that would rapid the tool down to a proximity sensor, move back up a few mm to clear it, then move over to the actual probe (a push button in this case). I like the idea of setting tool 0 to Z after homing, but with my recent machine upgrade, I have 150mm of Z travel. As David mentioned above, probing speed would take forever.
Yes, you can use a NPN type. Doesn't need to be 5v one either (harder to find) you can use the easier to find 6-36v ones with the Limits-V jumper on 24v
But then do I need to change the limit switches? I found a 5v IR break beam that may work better than the proximity sensor. My idea here is to have the IR sensor, xyz probe and a momentary push button all wired together into the probe port.
Oir switches are fine on 24v too Yes, the varying endmill diameters would not be as repeatable on inductive sensors as the varying frontal area affects the sensitivity All together should work if they are all effectively "normally open"
my Z probe uses a break beam from a laser printer. but instead of relying on the tool to break the beam (a 30deg Vbit will miss it more often than not, so will a 1mm single flute endmill) I build a mechanism, the tool presses on a bit of icecream stick which has a flange that breaks the beam. The longer the lever arm the more accurate it becomes, or less sensitive to exact bit placement. Optoisolated Z probe
Ahhh, right. I remember seeing that before. I was thinking of using this approach. I didnt think about smaller bits though.
I don't see a lot of need for it myself, the lions share of the time is taken up just changing the tool - it only takes about three seconds to probe it.
I agree that it doesnt take a ton of time. But its all part of a bigger project and at the very least, not having to attach the magnet and manually moving the bit down into an acceptable probing position is worth the effort for me.
