GrblHeightProbe2
GrblHeightProbe2 copied to clipboard
martin2250
Surprised by level traces
1st of all, you have created a 1st class (by any criteria) piece of software. You need to have a link to a donate button somewhere (I'd certainly kick in)!
That said, I was quite surprised by something I noticed.
I wanted to really understand what was happening before I wrecked/wasted any pcb material, so I created a map file 10x10points, 5mm grid with the equation "x*(.1)" to create a 50x50mm surface that's tilted up to the right. When I applied that to a small and fairly simple pcb gcode, I noticed that although traces start at the seemingly correct height, they stay at that height. For example, a horizontal cut starting at x=0 (z=0) will stay at z=0 even though by the time it gets to x=10, the material surface is now at z=.5.
Is that the intended behavior?
I figured it out. But not the solution.
The pcb2gcode output had a lot of lines that were simply: "Xxxx.xxx Yyyy.yyy"
Then when I edited them to be "G00 Xxxx.xxx Yyyy.yyy", everything was fine.
Im not seeing any pcb2gcode option that's going to fix that. Im using the 1.2.0 pcb2gcode thats bundled with pcb2gcodeGUI. I'll try using a later (1.2.1 or 1.2.2) version.
**** EDITED ***** I guess the lines should be prepended with "G01" (I'm new with this GCode stuff)
pcb2gcode 1.2.2 has the same "Xxxx.xxx Yyyy.yyy" lines that GrblHeightProbe2 seems to ignore. Should be fixable in GrblHeightProbe2, right?
Hi Mike,
great to hear that you like it! You'll have to wait two more months though, until I'm officially allowed to have PayPal (might talk to my parents for the mean time).
Regarding your issues with short-hand GCode: There is an option in pcb-gcode to use G01 in every line (all files that I could find in my eagle folder have them). I currently don't have EAGLE installed on any computer, so I can only guess that unchecking "compact gcode" in the "GCode Options" tab fixes the issue (according to the manual, page 14 it does). While you're at it, also check "Use simple drill code" as neither GrblHeightProbe nor grbl itself can parse G82 statements.
I won't add support for compact gcode in this version of the program anymore, the code already is too much of a mess. Instead I'll focus on completely re-written version "Open GRBL Pilot" which already can handle the compact format (it's not yet usable for actual jobs, right now only the 3D preview works). I think I'll continue working on it in march when most exams are over.
Greetings
Martin
1> If you're too young to have a PayPal, you're too young to write software this cool!!! Your Open GRBL project looks amazing and the world (and myself) will just have to patiently wait. 2> There may be an option to UnCompact GCode in Eagle(pcb-gcode), but there isn't (or doesn't seem to be) in the standalone pcb2gcode which Im using on my KiCad generated gerbers. There is an optimize flag, but that doesnt do what I need. 3> Since I already pulled down your code & built it, I might take a crack at adding it for my personal use. Or I might write a bit of python to process the compacted gcode file. Decisions, decisions. 4> Good luck with your exams, I suspect you'll do just fine.
Thanks mate! I didn't realize you meant pcb2gcode, I always get them messed up. In the mean time you can use GCodeRipper to add the missing G01s. Just open the file in GCodeRipper, go to the settings and choose mm over inches (or whatever you prefer) and save the file again. If you want to add support to GrblHeightProbe2, take a look here, specifically the variables "LastGCode" and "LineMovementCode". Hit me with a pull request and I'll release it ASAP.
In this project, file GCodeParser.cs, I changed line 67 from "Command = LastCommand;" to "Command = 01;"
LastCommand can then be done away with;
That seems to do it, but some (more) testing would be appropriate.
This is no appropriate fix, shorthand-GCode can also contain multiple G2/G3s stringed together, so always assuming G1 would be incorrect. Looks like I already implemented it in this version, I don't know why it doesn't work. Anyways, your fix should work for you but it's no permanent solution.
Hi, I couldn't help myself and started coding away: https://github.com/martin2250/OpenCNCPilot/releases. In case you are interested in the new version. If you still need a good program to fix your shorthand gcode problem, you can use this (and report all issues with parsing to me of course :grin:)
I'll check it out. In the meantime i discovered that the stock Shapeoko2 spindle wasn't nearly up to the task of making a reasonable pc board. What are you using? ---- martin2250 [email protected] wrote:
Hi, I couldn't help myself and started coding away: https://github.com/martin2250/OpenCNCPilot/releases. In case you are interested in the new version. If you still need a good program to fix your shorthand gcode problem, you can use this (and report all issues with parsing to me of course :grin:)
Reply to this email directly or view it on GitHub: https://github.com/martin2250/GrblHeightProbe2/issues/18#issuecomment-180879721
I'm using a Kress 800, it's pretty good as it can reach 30k rpm (small cutters generally need higher rpms). It uses a lot of power though and makes a lot of noise.