1/4" dowel from Mcmaster Carr, pretty cheap and .0002 tolerance.
That would do it.
I’m sure if he integrated with software, someone would buy it.
How about just using some 1-2-3 blocks.
Grbl will report the machine co-ordinates of the probe touch point. If you home your machine, should be able to work the math to get an accurate conversion to steps/mm.
[Edit] - could be done without homing - wouldn’t be as easy.
But can you get those coordinates inside of the Gcode without an external UI? That’s where I see this breaking down and requiring a UI (for those wanting a less manual approach).
I’d personally just use the outputs in UGS and calculate it all.
Stack the 1-2-3 block on top of your flat bar. Probe to the flat bar for Z and then probe to the top of the 1-2-3 block. You could use either dimension of the block depending on how much Z travel you have.
Any idea what the code would look like?
And can we parse it in English then translate it to g code?
1 machine Zero
2 Probe X+ N amount
3 Probe X- N amount
4 Calculate based on (X,Y,Z) $100-102
5 Send $$=New N
Here is set of gcode commands that will get you part way there. The problem I think you will run in to is that you can not do calculations in grbl. It will not use any variables to store calculations, much less do the calculations. I think the only way your going to get where you are trying to go with this is with some software that you:
- Input the starting steps/mm setting from grbl, the length of the piece to be probed, and the bit diameter. (The code below assumes a 1/4 inch bit.)
- Run the below gcode to determine the distance that they machine thinks it moved and enter that value in the software.
- Tell the software to calculate the discrepancy and provide you with a corrected Steps/mm for that particular Axis.
- Issue a command to grbl to update the Steps/mm to apply the corrections.
This code would probe a plate 5 inches long. It is written to run in millimeters since the corrections in grbl will be in millimeters and that would eliminate the need for converting from inches to millimeters.
The software required to do this could be something like the Triquetra Tool Box or even an Excel spreadsheet. Both would be capable of doing the math and generating the gcode. It would require a separate gcode file for each axis.
G92 X0 G92 Z0 G21 G38.2 X25.4 F100 G92 X0 G91 G0 X-5 F300 G91 G0 Z-25 F300 G91 G0 X151 F700 G91 Z-25 F300 G38.2 X-25 F100 G91 G0 X5 F50 G91 G0 Z25 F300 G91 G0 X-11.35
For me, the hard part of all this would be writing the code that would allow the program to communicate with the CNC and send the code. It might be less complicated than I think but I’ve never looked in to it.
I wish you the best of luck. I don’t know diddly about Java programming.
We may have criticisms. But no guarantee on the construction.
You could do this with a simple Python script instead of going full-on Java.
Yea my SW of choice (LabVIEW) is something I can almost guarantee that nobody has installed but it’d work well and be efficient. It’s what I do at my place of employment.
But as a backup, you could go with Python if Java is just too cumbersome.
I have access to a very experienced programmer who knows a ton of languages. What’s the ideal/universal language to write such a program in?
Great Idea, the thing with calibration is you want to calibrate the longest distance of travel which helps to compensate for any back-lash that you may have in the axis and it is a more accurate method for calibration. I do like the idea of using 1,2,3 blocks mounted to an extrusion perfect adjustable solution. If you use a calibrated SS dowel you can create a digitizer program similar to that of the touch off zero plate and automate the process. I have not written a file to do this as of yet because I have many time constraints to deal with and all of my projects have been put on the back burner. Nevertheless, ya’ll are heading in the right direction. One more thing when you calibrate the process should be completed several times to test for repeatability. Let me know if you have any questions.
Java has historically shown to be one of the most cross-platform friendly languages but at a cost of performance.
However, for this particular application, it would be the closest match but its still not a guarantee that everyone has the proper version of Java installed (one of numerous drawbacks to Java). You’re also dealing with the overhead of Java in order to create a simple UI, given you want to create a simple UI.
It’d be interesting if it could be written as an add-in to a program like UGS. I think the new Platform version supports plugins now.
Wrong. I have version 2009. Have used it for years testing rocket motor propellant formulas.
Love the development environment.
Use $# to get the probe value (machine co-ordinates - mm)
G38.2 Z-0.25 F1
I said almost
That’s what I’ve done for the last 10 years at work (my entire career). I started with LV7.1 and 8.5 and have migrated throughout the different versions. Currently using LabVIEW 2016 and will probably jump to 2018 with the next project. It’s gotten quite a bit better over the years I’ve used it.
I love it. It’s incredibly easy to do some rather complex stuff. We were doing some real-time signal impairment at my old job. It handles incredibly large data sets relatively easy.
I’ve debated about making a Gcode sender using LabVIEW but the time involved would be more than I can do right now. Maybe one day.
I asked around, and why cant UGS do the calculations?
plug in? Does grbl do linuxcnc? or is grbl linux cnc? or arduino for that matter?