first coordinate of hight probing misses surface

[deHarro]

I used probing for milling a printed circuit. When I start probing on a new 40 by 30 mm grid, the sensor moves way too far into the PCB for the first probe. Luckily I use spring probing contacts, so nothing bad occurs, but the resulting coordinate field has a kink at the front left edge (X Y zero).

Since you all made PCBs on your own and all works well, I suppose I did some mistake in setting up the process of probing?

[martin2250]

Hi Harald,

that's a pretty strange issue, I assume you checked the board for any major contamination, and, depending on your spring probe, that too. Does this happen every time or just this once? Also, you'd save a lot of time by setting Z-zero at the actual height of the surface so the probe doesn't have to travel the entire distance every time, then you can also use it as a reference surface for toolchanges more easily.

[deHarro]

Hi Martin, it happens every time.

And I realized another effect, but I am not sure if I did a mistake: You see in the picture that the plane is some amount below the probing grid, which sits on the origina lzero point (X=Y=Z=0). As far as I remember I started the probing at Z=0 (I hit "Probe" in the "Jog" menu of Pete's (Northernboy) version of OpenCNCPilot, so the program should know Zero.

Ah, just another hint you should be beware of! Pete and I just at the moment are "debugging" some error messages arising when working with GRBL 1.1. I used Pete's version when I got that kink in the plane. On the way of progress, I got a moving Arrow when processing a g-code file for the first time! This is the effect of interpreting the status answers of GRBL in the correct way, so perhaps this probing error depends on misinterpreting GRBLs answers. I will test the probing again when Pete has the final version of his program and report. Harald

[deHarro]

Hi Martin, before I dive into the cellar to test your new version for GRBL 1.1f, perhaps I should ask for some advice on how to start the hight map probing. What I did:

1. Apply Z=0 by "Probe" with Petes version. With your current implementation I have to zero the Z axis by optical means or by putting a paper between stylus and surface?
2. Start probing the hight map -> Stylus moves up and again down to zero Z until it hits the PCB, then step by step all check points until the last one. There the stylus moves up to Z~10mm and stops. -> Nice feature would be to return to X=Y=0, Z=10 (or so)
3. Menu Edit -> Apply Hightmap --->> Here I see, that the colored map in the viewport lies around 1 mm below the probing grid. I would expect to have grid and map having the same hight?
4. Next: Again position the stylus at Z=0 (by some adequate means), just above the PCB
5. File -> Start. Now the stylus moves up to Z~10mm and back down. -> Then it dives this 1 mm into the PCB, way too far!

So where is my fault?

To test the new version I have to upgrade my Arduino to GRBL 1.1. Just starting...

[martin2250]

Hi Harald,

1. You can enter the probing command manually: G38.2 Z-10 F20, then G92Z0
2. Yes, it should move up to 5mm for the first point, then slowly come down until it hits the surface. It will only go up around 2mm for subsequent points.
3. Ideally the map should line up exactly with the XY-Grid
4. DON'T. You already set your origin, so the machine knows where it is. I guess your fault lies with setting the Z origin correctly, in your gcode, the tool should plunge around 0.15mm deep, and the height map should only change that very slightly. At least at the origin (where you set your Z reference) the depth should not change when applying the height map. In any case the machine will follow the new toolpath exactly, so best inspect that (search for any Z command words in the list) if you are unsure.

[deHarro]

Hi Martin, my mill is now set up with GRBL 1.1f, I tested probing (Z=0 probing) with G38.2 ... as you said above. -> Bit moves UP some steps and ALARM is raised. ...some investigation later... Ah, I got the point(s)!! :-) Firstly: The stylus in the viewport sits somewhere below the origin, so I think coordinates and moves are inverted(?) and additionally the ALARM is raised because I am below Zero Z. Second: After fixing that (G92 X=Y=Z=0 -> stylus and origin fit together), I could enter your code G38.2... and probing starts and finds Z=0 properly. Now I set up the grid and start probing, all went as expected. End of probing: Bit moves up and stops.

Now comes my fault on my last tries: I now moved the bit to the origin (as I did all my life with other g-code streamers) to start milling. As you describe above, OpenCNCPilot knows already that it stays somewhere offset to the end of the probing grid and has to move to Zero on itself to start milling. So OpenCNCPilot drives back to Zero (again, not knowing that I already did that) and crashes into the PCB and afterwards moves to -X and -Y (negative) what crashed my stylus. (End of faulty handling)

Ok, got it! Let the tool do what it knows best and all will be fine... :-)

Have I said that I badly miss the Jog menu of Petes version? ;-)

[martin2250]

Bit moves UP

if you enter "G38.2 Z-10 F20", the machine will only move up if the machine is set to absolute coordinates and is currently below Z-10. G38.2 behaves just like any other motion command.

It will only raise an alarm if it already detects continuity before it starts moving down.

Other than that, no gcode streamer should behave any differently. Once you set your origin, you can move around and start your file wherever you want (unless the file is written using incremental coordinates, which would be very unusual (and stupid)) and the machine will move to the position that's specified in the file.

OpenCNCPilot will NOT move to zero when you start a file (or for any other reason unless you explicitly tell it to). This must be part of your gcode file.

Anyways, does it work as expected now?

About the jogging menu: GRBL introduced the new jogging functionality which allows you to stop the jogging motion mid-way without loosing the position. That's why I only implemented the keyboard jogging (so it will stop when you release the key), unlike Pete's "old" way of just having buttons with a fixed distance.

[deHarro]

Mhmm, ok. Only one slightly intervention to your writings above: You stated, that OpenCNCPilot "knows where it is" and I don't(!!) have to Zero again after probing the grid. Having learned that, I left OpenCNCPilot where it is after map probing, loaded my file and applied the map. The I hit File-Start and OpenCNCPilot moves to Zero and began to trace the milling path. Fine, as expected, so far as I understood your text above.

My g-code starts with:

(.../pcb-gcode-3.6.2.4/pcb-gcode.ulp) (Copyright 2005 - 2012 by John Johnson) (See readme.txt for licensing terms.) (This file generated from the board:) (.../Isolationsfräsen_Tests/Iso_1/Iso_1.brd) (Current profile is .../pcb-gcode-3.6.2.4/profiles/generic.pp ) (This file generated 10.03.2017 20:07) (Settings from pcb-machine.h) (spindle on time = 3.0000) ( Tool Size) (0.1000 ) (spindle speed = 30000.0000) (tool change at 0.0000 0.0000 40.0000 ) (feed rate xy = F508.00 ) (feed rate z = F254.00 ) (Z Axis Settings) ( High Up Down Drill) (12.0000 2.5400 -0.1778 -0.8128 ) (Settings from pcb-defaults.h) (isolate min = 0.0254) (isolate max = 0.5080) (isolate step = 0.1270) (Generated top outlines, top drill, bottom outlines, bottom drill, ) (Unit of measure: mm) (Metric Mode) G21 (Absolute Coordinates) G90 S30000 G00 Z12.0000 G00 X0.0000 Y0.0000 M03 G04 P3.000000 G00 Z2.5400 G00 X1.5551 Y1.8609 G01 Z-0.1778 F254.00 G01 X1.5184 Y1.9245 F508.00 G01 X1.4994 Y1.9953 G01 X1.4994 Y5.6247 G01 X1.5184 Y5.6955 G01 X1.5551 Y5.7591 G01 X2.2154 Y6.4194 G01 X2.2154 Y6.8437 G01 X2.5543 Y7.1826 G01 X3.0337 Y7.1826 .....

Somewhere in the middle I read "(Absolute Coordinates)". This might be the reason for the erratic behavior of my mill when starting the job after map generation? If so, it should work as expected when I set X=Y=Z=0 just before beginning the job, right? Perhaps I missed that (just moved the bit to zero but forget to tell that to OpenCNCPilot by entering G92 X0 Y0 Z0). Would that explain it?

By the way: I'm very interested in your G-code jogging. I also implemented that on my Joystick but the arduino is too slow for generating the G-code strings in parallel for three axis.

nota bene: The stopping midway seems to not function properly, there is already an issue on GRBL 1.1 and Jeon said, he will have a look. The issue is not mine, but I realized that too.

[martin2250]

G00 Z12.0000
G00 X0.0000 Y0.0000

Exactly, these two lines tell the machine to move to XY zero above the PCB surface. Also G90 tells the machine to switch to absolute coordinates, so this can't be cause for any erratic behavior.

Again, only set your origin once, before starting the probing process or you'll throw off the alignment of the heightmap. The only exception would be to raise or lower your Z-origin by a few tenths of a millimeter if the bit doesn't cut all the way through the copper.

Could you link the issue with stopping jog commands? I couldn't find it (I also didn't have any similar problems so far).

[deHarro]

I'm sorry, didn't find it either... might be fixed in the meantime? Is there a way to search for closed issues?

[deHarro]

Found it: https://github.com/gnea/grbl/issues/95 It's actually closed, they found a trick to get/stay in sync 4 days ago.

[martin2250]

Thanks! it looks like it was an issue with the gcode sender application. Did you have this issue with OpenCNCPilot?
From what I gathered, this issue occurs when you send many jog commands repeatedly, which OpenCNCPilot doesn't do.

[deHarro]

Hi Martin, when do you think you provide us with your next version? You know, Jogging menu enabled, perhaps Z=0 probing per button, and all the other goodies we even can't think of... ;-)

By the way: I asked Pete if he might implement a second serial port where I can attach my Arduino nano to send analog values from my joysticks which are to be translated into jog commands for GRBL. Don't know whether he still thinks about it, but your own approach for jogging seems like ideally fitting for my idea. If implemented I just had to send three analog values and some additional code in OpenCNCPilot has to translate this into already available jog commands. Sounds fairly simple. If you have those additional routines it is imaginable to even support any sort of joysticks or gamecontrollers around. Just an idea... sadly I am unable to extend your program on my own, my C# skills are slighthly above those of lettuce :-(

Harald

[deHarro]

Oh, I forgot to comment on your last writing...

There is no interaction of my joystick and OpenCNCPilot yet, so No, OpenCNCPilot has no problems with jogging, as far as I am concerned.

But my implementation of jogging in the second Arduino has this (or a very similar) issue with GRBL 1.1. I try to send very fast short moves as long as the stick is deflected from neutral. I understand, this is the recommended approach for jogging. The F parameter depends on the amount of deflection, the step size is fixed (e.g 0.1 mm. I tried different numbers. Don't know what "chamnit"s "very short movements" should be). I send strings of the form "$J=G92X-0.10F532" where nearly all chars are fixed. Only variables are the axis parameter (X, Y, Z), the sign ("-", Blank) and the number behind "F", denoting the feed rate.

Besides the fact, my Arduino is too slow to keep the look ahead buffer filled for a smooth movement, I have the problem, that after sending the "jog cancel" command, the axis stops and then does some additional moving. This behavior is arbitrary, doesn't apply all the time and the amount of additional movement - if any- is arbitrary, too.

[martin2250]

Sorry, but this is just too specific to implement. I'd have to cover all sorts of setups with joysticks being read by Arduinos or just using USB joysticks etc. also there are just so many things to consider making this failsafe: -can it execute commands while sending a file? -should it pass along special characters like soft reset while sending a file? -should it accept special commands to start a file/probing cycle?

There is just no way to make it usable for everyone. If you do find a way to make it universally usable and keep the additional code fairly lean let me know and reopen this issue.

[deHarro]

Perhaps you think too complex, but I can follow your thoughts. Too bad :-(

But allow some thoughts about your concerns. The different setups... Arduino: Define an API, the rest has to be handled by the Arduino. Proposal: 3 integers with analog readings of 3 joysticks (0..1023). USB: Leave it alone, there are already solutions covering that (mostly in conjunction with mach3).

Intermix of g-code and jogging... Your code should already provide some means of allowing only one sort of input at a time. Think of running a g-code file and issuing jog commands via your buttons. [edit] ok, I found your method for interlocking. It works for me. I think you could use the same mechanism (even the same dialog).[\edit]

Special chars... Only "jog cancel" should be allowed on this interface, and only if jog commands are underway or status is idle.