Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Height map irregularities #550

Open
104TMR opened this issue Apr 24, 2022 · 58 comments
Open

Height map irregularities #550

104TMR opened this issue Apr 24, 2022 · 58 comments

Comments

@104TMR
Copy link

104TMR commented Apr 24, 2022

Hi Denvi,
Many thanks for a great piece of software.
I'm using Candle 1.1.7 with a Vevor 3018 CNC mill to mill PCBs.

I undertake a height map before any PCB mill, and tick the box in Candle to use the map, but I'm finding that the height map doesn't seem to be providing the height corrections that it should. The cutting tip (0.1mm, 30deg) cuts down through the copper layer in some areas, but then only cuts part-the-way-through, or not at all, in others.

I decided to check the consistency of the height map process, and ran 10 consecutive height maps over exactly the same area (10 point x 10 point, height map probe feed =10), and looked at the .map files these runs created in Excel.

I've been concerned to find some dramatic and variable differences between the (what-should-be identical) height map coordinates.

I selected the first (of 10) height map as a reference, and then subtracted each subsequent height map array from the reference, and looked at the resulted difference arrays.

These different height map arrays showed fluctuating differences, both in their magnitudes and distribution. While most deviations fell in the -30 micron to +30 micron range (still surprisingly large, considering that the copper layer on a 1 oz PCB is 35 micron), several difference maps showed some points that were 200 to 900 micron deviant(!).

These latter figures are clearly in error, but it seems they all might be, as no two deviation arrays were the same. I would have expected to see typical machine and randomisation errors of 0~5 micron, perhaps, but not 20-30 micron, and certainly not 200-900 micron.

Could I ask your comment on what you think may be happening here?
I can send the Excel file with the height map difference arrays, if it's useful.

Many thanks for your help,
Glen
@Jarewa
Copy link

Jarewa commented Apr 24, 2022

Increase step accuracy and decrease point homing speed.

Because how many steps do you have per rotation?

@104TMR
Copy link
Author

104TMR commented Apr 24, 2022 via email

@Jarewa
Copy link

Jarewa commented Apr 25, 2022

Send the command $$ and write what you have under the items $100 $101 $102

10(mm/sec) the slower the better

@mar0x
Copy link

mar0x commented Apr 25, 2022 •
edited
Loading

Hello,
The Feed rate is specified in "units per minute". For G21 it is "mm per minute".

@104TMR , I would recommend to check the accuracy of the probe process itself. Repeat the following command sequence in console:

G21 G91 G38.2 Z-40 F10  ( do the probe and check the last number in response [PRB:0.000,0.000,-1.031:1] Z=-1.031 )
G21 G91 G0 Z1 ( move the spindle 1mm up )

Check the dispersion of Z probe response. If it is stable enough, then it makes sense to continue your investigation.
( I've got -0.011 .. -0.013 for first 5 probes, then it changes to -0.028 .. -0.031 for latter 6. But I'm using V-cut as a probe for copper PCB and each probe may push in a copper layer a bit. )

The probe process is sensitive to feed rate: the lower feed rate the more accurate result. Candle 1.1.7 does not use "Heightmap probing feed" setting value at all. The last movement feed rate is used. So, try manually execute the sequence above right before the heightmap probe and control the feed rate in a left-top corner. Consider unofficial v1.1.9 with fixed "Heightmap probing feed" setting usage and reasonable small feed rate configured (10 - 30 mm/min).

@104TMR
Copy link
Author

104TMR commented Apr 25, 2022 via email

@104TMR
Copy link
Author

104TMR commented Apr 25, 2022 via email

@104TMR
Copy link
Author

104TMR commented Apr 26, 2022

Hi Max, I tested your two lines of code, and got z-depth readings that stayed within 1 micron of the 1st reading over a set of 10 readings - which is a great result!
Question still remains: Why does a set of repeated, identical height maps produce differences of up to ~20 micron?
However, I've done some reading, and noted that it looks like the max. steps/mm for the stepper motors can be up to 1600. So, I've set z-steps/mm to 1600 ($102=1600, leaving $100=$101=800) and rerun the multiple (10) height maps.
Remarkably, the array of differences of each height map from the average of all height maps are showing maximum and minimum values of less than 7 um, which is 3x better than what I was achieving previously. I have since done a new height map and run a PCB routing run using the new steps/mm, and the cutting depth consistency is much better.
Proof of the pudding...

@mar0x
Copy link

mar0x commented Apr 26, 2022 •
edited
Loading

got z-depth readings that stayed within 1 micron

So, the probe itself works fine when the probe runs at 10 mm/min feed rate. Perfect!

Have you checked the actual feed rate during height map producing (at the top left corner, next to F/S) ?

Grbl $102 setting is the number of steps for stepper motor to move spindle for 1 mm along Z axis (source). It is conditioned by your stepper motor and driver (the number of steps per rotation) and mechanics of you machine (lead screw step). If you have 800 steps/mm and your Z-axis movement is 100% accurate it is incorrect to set $102=1600 just because your Z axis starts moving twice longer (in mm). This is it. There will be no double precision etc. And you've got better probe results just because movements along Z-axis are doubled. Use the ruler and measure the height after "G21 G91 G0 Z20" command (there should 20mm difference).

@104TMR
Copy link
Author

104TMR commented Apr 27, 2022

Yes, I see what you're saying, Max. Indeed, setting $102=1600 makes the z-displacement 2x what it should be.
Clearly, I'm a novice with all of this.
So, I've reset $102=800, set the probe speed to 2 mm/s (and Yes, F/S reads 2 (or whatever speed I set it to in the Height Map Settings, so it does seem to get it's value from there)), and rerun 10 height maps, and find much the same as previously: differences of +/- 17 um.
So, why can the machine get such repeatable precisions of 12 um in a single test mode (using G21 G91 G38.2 Z-40 F10, etc.), but such lousy precisions when doing a height map (even with a very slow probe speed of 2 mm/s)?

@104TMR
Copy link
Author

104TMR commented Apr 27, 2022

Sorry, "12 um" should be "1~2 um"...

@chfgwd
Copy link

chfgwd commented Apr 27, 2022 via email

@mar0x
Copy link

mar0x commented Apr 27, 2022

Hello @chfgwd ,
Actually this is the issue tracker for Candle and in this issue we're trying to understand and solve heightmap probe inconsistency. You are welcome to participate in discussion too!
The answer for you question is $32=1 and we're expecting your instant contribution.
Best regards.

@104TMR
Copy link
Author

104TMR commented Apr 28, 2022

I've been doing a number of height map tests under different conditions, but haven't got to the bottom of why z-differences are so small when measured at one point, and why they start varying so much when tested between varying x-y positions.
Following are some descriptions and plots of the results. Interpretations to follow.
The height map scans were a 50x50mm square of 4 points (ie. each corner). The 4 depths recorded at each corner were averaged over the 10 scans, and then each of the 4 points for each scan were subtracted from the average (to create differences from the mean), and the minimum and maximum values for each scan plotted vs scan number.

  1. I wondered if the z-probe trigger signal may be affected by RFI from the z-stepper motor (I notice that the nearby AM radio gets heavy RFI when the stepper motors run, so I put a 0.22 uF capacitor across the A5 terminals, to dampen any RFI that could affect it. Didn't make any difference.
    HeightMapDifferencePlots-2x2-Max_MinDifferencePlots-WithFilterCap
    Image shows maximum and minimum deviations from the mean for 10 scans.
    Shows min/max ranges of approx. +/- 15 um.
    What does stand out from the plot is the apparently strong correlation between max and min values across the scans.
    This seems to imply that when the maximums are going up, so are the minimums, and vice-versa.
    If we were dealing with a purely random effect causing the variations, we would not expect to see correlation between the max and mins - instead random effects would make the values independent of each other across the scans (disagree if you like...!).
  2. To check this further, I disconnected the capacitor, and ran three more 2x2 scans of 10 scans each (ie. 30 scans in total), to see if the max/min correlations continued. It looks like they do:
    HeightMapDifferencePlots-2x2-Max_MinDifferencePlots-NoFilterCap-1
    HeightMapDifferencePlots-2x2-Max_MinDifferencePlots-NoFilterCap-2
    HeightMapDifferencePlots-2x2-Max_MinDifferencePlots-NoFilterCap-3
  3. So then I thought that perhaps a systematic offset may be associated with one axis drive (X or Y). So I did a set of 10 height scans between two points on the X-axis, and then the same for the Y-axis. Plots below show the max/min differences vs scan number, and the correlation seems to have disappeared:
    HeightMapDifferencePlots-1x2-Max_MinDifferencePlots-XVariationOnly
    HeightMapDifferencePlots-1x2-Max_MinDifferencePlots-YVariationOnly
  4. I then did several height tests at single points (ie. not moving the X/Y position), and found that the height differences reduced to 1~3 um, as found previously.
    This seems to be showing that when you don't move the X/Y dimensions, height values are very precise.
    However, as soon as you start moving around in the X/Y dimensions, variations creep in, and make the height map fairly unreliable.
    I don't know what else to interpret from all this.
    Further thoughts appreciated from anyone interested in this topic.
    Does anyone else experience PCB isolation routing showing unreliable depth cutting - or does everyone else's projects work perfectly and mine's the only dud?! ;-)
    Thanks for any thoughts...

@Jarewa
Copy link

Jarewa commented Apr 29, 2022

What screw do you have, TR8x2?

@104TMR
Copy link
Author

104TMR commented Apr 29, 2022 via email

@Madbyte3d
Copy link

104TRM,
I think that you are not alone. I've been pulling my hair for a week or so because of inconsistencies in isolation routing. My case is a bit different in that sometimes I get really deep mills, and therefore wider mills. For a while the tip was barely touching the pcb and just engraving it. I made a very basic circuit to repeat the test.
Screenshot 2022-05-29 175418

In my case all the isolation maps increase in height as the probing progresses from bottom left to top right. This means that my spoilboard is not level but the thing is that I just surfaced it with a 1 inch surfacing bit.

Do you mind sharing the height map parameters that go with the charts you shared above? Also the excel you are using for graphing? I'll attempt to run the same tests generate the graphs and report back.

I'm new to CNCs but have several years of experience with 3d printers so I understand the mechanics of the steppers motors and controllers. Is a different mindset when it comes to the relationship between the tip of the bit and the surface and having two sets of coordinates to deal with.

I have a Sainsmart Genmitsu 3020 Pro Max if that's important to anyone.

@104TMR
Copy link
Author

104TMR commented Jun 1, 2022

Hi Madbyte3D,
I guess it's good, but also disappointing, to hear I'm not the only one with clumps of hair on the floor over this issue!
I still haven't been able to get reliable height mapping working.
The following recent results show the overcutting of tracks, despite running and applying a height map:
IMG-4014
I'm also attaching the Excel file I use to do the height map difference comparisons:
ExampleHeightMapDifferencePlots-2x2-MultiRuns.xlsx
The way you use it is as follows:

  1. Run a series of height maps, saving each one with its own file name as you go. The Excel file is setup for a 2x2 (ie. 4 points) map, and I generally use a 1/4, 3/4 layout, eg. on a 100x100mm board, I would map at (25,25), (25,75), (75,75), (75,25).
  2. Open each height map (Notepad, Wordpad, etc.), and drag over and copy the last two lines in the height map, that contain the height measurements at each probe point (values are separated by semicolons).
  3. Go to ExampleHeightMapDifferencePlots, drag over the 4 cells coloured orange, and hit Paste, and the 4 height values should paste straight into the cells. Do this for all 10 height maps.
  4. The means of the 4 height points are calculated in AF3:AG4, and the array formulas, based on the formula in B8:C9 calculate the deviations of each height map from the mean.
  5. The charts show various measures of the deviations using different metrics, which I think should become fairly self explanatory when you examine the cells and look at what each chart is plotting.

It will be interesting to see how you go applying Max's formula at a single point:
G21 G91 G38.2 Z-40 F10 ( do the probe and check the last number in response [PRB:0.000,0.000,-1.031:1] Z=-1.031 )
G21 G91 G0 Z1 ( move the spindle 1mm up )
My machine showed very good repeatability using this at a single point, but it all seems to go to pieces when you start trying it across a range of x,y positions.
Let me know how you go!
Cheers...

@scorninpc
Copy link

Hello guys!

How are you going with this problem?

I've tested all in this issue, and recreate all the tests, and got the same results with no fix

So i decided to add 1/32 microsteps, and got some better results, but no success yet

So i tried to link my oscilloscope to see whats happening, i saw alot noise.

I added a pull up with divider to trigger SCL, creating a route for noise escape

image

image

and i got a nice result

3 times sequentially of the same point

image
image
image

This occured on 8 tries, but sometimes keep falling

image

but it's reduced by 80~90% of errors

Maybe it is a direction. I need work better with this resistor values

@104TMR
Copy link
Author

104TMR commented Aug 31, 2022 via email

@scorninpc
Copy link

Ok for probe tests, but no acceptable on map height =/

image

@pixelwaster
Copy link

Here is a video I found interesting, A quick demonstration on how much overshoot happens when you use continuity based probing.

From what I understand, the overshoot is a result of the feedrate and stepper acceleration, The faster the acceleration and slower the feed, the less overshoot.

Stop probing with your tool

@scorninpc
Copy link

Nice video. But i think he show the precision of probe, not the different results of the same points (you can see he moving the plate with hands alot time)

Anyway, today i'll do some tests with acceleration, becase i done alot with speed, bot not with accel

Thank you

@mar0x mar0x mentioned this issue Sep 10, 2022
Open
@scorninpc
Copy link

I found a loooooonnng discution of that gnea/grbl#96

And the summary: https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches

I ordered the optos, and will test with probe as i can, and post results

@104TMR
Copy link
Author

104TMR commented Sep 16, 2022 via email

@scorninpc
Copy link

Sorry, but i think you dont understand your first problem, and dont read the related links.

All this problem is causes by noise and the links is about cut that, isolating contacts with opto-isolation

The height map irregularities is not caused by software problem, but by measurement

@104TMR
Copy link
Author

104TMR commented Sep 19, 2022 via email

@mar0x mar0x mentioned this issue Oct 11, 2022
Open
@Mot007
Copy link

Mot007 commented Aug 8, 2023

I have been reading and following your comments re the height map inconsistencies. I recently bought a 3018 pro and also tried to cut a simple circuit PCB 108x30 cm.
I have almost broken every bit In the process to try and auto levelI. I am a retired hardware engineer. Sometimes the hardware is not what it should be and the battle of the software versus the hardware is still evident! I put a scope on the input if the Z probe and to my amazement saw quite a lot of bounce. The problem as I see it is on the second reading and again I'm not sure what the software is doing.
But it seems that the first plunge gets a clean low upon touching the copper. Then the probe rises and descends to get a more accurate height reading. This is where lots of bounce occurs. As the smaller steps just kiss the copper, lots of high resistance connections appear causing irregular connections untill rock bottom connection occurs.
A simple solution would be to step down, denounce for a given time, read, and repeat. Another solution would be to increase the pull up on the sense input to much greater than 10k maybe even 100k . I have captures of this but don't know how to share it with you. I'm happy to do so if you show me the way.🙂

@Mot007
Copy link

Mot007 commented Aug 8, 2023

20230808_181503
20230808_181450
20230808_180902

@Mot007
Copy link

Mot007 commented Aug 11, 2023

Hi TMR104,
I have gone along the path of a hardware fix to the noise and have not made much of a difference. Today I tried a few different ideas and have had a much better result in the deviation for the same map. I have proven to be definitely sure that a Shap tip will increment the error on every read. This is due to the initial velocity to make contact and also the subsequent slow plunge makes a difference. Coupled together with a flat probe will reduce the error for the same point .
This all fell to bits once I repeated a simple height map (30x30mm) 3,3 probes.
What I found is that the plunge is F10 and could not find where to alter this. More importantly the inaccuracy deviation seems to show much greater as the machine scans the centre points traveling right to left. ? Much more investigating I guess.
Are you able to point me to the software? I could only have a go but not qualified in that department.
On the other way of producing, what is the minimum track/space that you can get which Lazer?
I only have a 2.5W one and have not fired it up as yet.

@104TMR
Copy link
Author

104TMR commented Aug 11, 2023 via email

@Mot007
Copy link

Mot007 commented Aug 11, 2023 via email

@tmr4
Copy link

tmr4 commented Aug 13, 2023

I've been having the same height map issues. Has anyone tried using the average of several height maps? Did it help at all?

@Mot007
Copy link

Mot007 commented Aug 14, 2023

Have been working on this and have found some promising results. I'll have to fine tune it and will let you know the fix.
Here's a quick result. I haven't saved the record before the fix but they where out by about .050mm
Here's what I got recently
4 probes 30mm square using 60deg V cutter
probed 4 times different set up. 1 is .001
p1,p2,p3,p4,err
0, 0 0 1 1
13 ,12 ,12 ,14, 2
57 ,64, 62, 68, 11
57 ,66 ,68 ,61 ,11

5 ,0, 0, 0, 5
21 ,16 ,16, 16, 5
57, 55, 50, 49, 8
59, 54 ,52, 53 ,7

@tmr4
Copy link

tmr4 commented Aug 14, 2023

I took 5 height map runs for a 40x40 mm board I'm making, discarded the most inconsistent one and averaged the others for the final height map for the board. The board milled successfully. The first for this size of board for me. One sample doesn't prove the technique, but I'm very happy with the results.

I also tried doing the height map of the same area with different types of bits and even the flat end of a bit shaft. I found that:

  • most times the first height map after changing a bit was a throw away and if not one of the others was different enough to consider not using it;
  • I occasionally saw a spark as the V bit approached the circuit board. Could this account for map irregularities? I can't say as I didn't observe closely enough to make an assessment.
  • the maps made using the flat end bit had the lowest standard deviation of all of the bits. This makes sense since each probe itself is effectively averaging a very large area around what would be measured by a V bit.

I used an average of the flat end maps for my successful board.

@Mot007
Copy link

Mot007 commented Aug 15, 2023

Hi Tmr4
Good for you to getsome +be results!
What I have found is that the firmware does not denounce the probe input adequately.
But having minimal software expertise, I've resorted to a hardware mod on my driver board. Which is a Chinese derivate using a stm38f030 arm controller. Somewhere along the translation they lost the recipe. I don't believe it is the Candle software at fault but the glue software that goes with the GRBL firmware or the GRBL firmware itself.
I can't pinpoint it but my hardware mod to my Chinese PCB has allowed me to get a much more precise leveling map that I could ever achieve before. I can live with +/-10 microns on copper probing with a sharp .2mm probe. I take the second reading as the correct one.
All the best.

@104TMR
Copy link
Author

104TMR commented Aug 15, 2023 via email

@Mot007
Copy link

Mot007 commented Aug 15, 2023

Hi 104TMR,
You are right it should say 'debounce' and '+ve' 🙂
I am more than happy to share the results.
Once I have a moment I will write it up and share it.

@Mot007
Copy link

Mot007 commented Aug 19, 2023 via email

@Mot007
Copy link

Mot007 commented Aug 19, 2023

probe1.pdf

@104TMR
Copy link
Author

104TMR commented Aug 19, 2023 via email

@tmr4
Copy link

tmr4 commented Aug 19, 2023

The software (GRBL) is just monitoring the probe pin in probe.c probe_state_monitor(). The probing cycle takes place in in motion_control.c mc_probe_cycle(). It looks like it is simply checking if the probe pin goes high or low (this is configurable) during the stepper ISR. I don't think there is any software debouncing.

@Mot007
Copy link

Mot007 commented Aug 19, 2023

I'd be happy if someone tried the probe to say if it work for them or not. I don't have much confidence on my Chinese supplied hardware. For instance , I changed $102 to half the value (800 to 400) and had no change on the distance travelled🤔

@tmr4
Copy link

tmr4 commented Aug 19, 2023 •
edited
Loading

We clearly have different hardware. The voltage across my z-probe is greater than 11 volts and exhibits very little bounce. When there is bounce, the rise is slowed from 2 to 5 ms. I'm guessing that this timing was selected to ensure the low state is seen by at least one cycle of the z-stepper ISR. Here's the oscilloscope trace of my typical probe:

Typical Trace

Here are a few less frequent traces with a bounce:

With bounce

With bounce

Clearly all isn't good since I've had problems as well. It's just something else. I think in part it's setting the height at the start of the milling operation consistent with that of the height map. I think the z origin needs reset with the z-probe after the height map is done. I haven't been doing this.

@Mot007
Copy link

Mot007 commented Aug 19, 2023

Hi TMR4
Firstly, I'm surprised at your probe voltage for today's type logic runs topically either at 5 O 3V. Check your CRO for X1 or X10 setting.🙂
You seem to have found the part of the proving in the ISR which makes sense as a non software person, correct me if I'm wrong, I presume the stepper is called by a timer ISR as the stepper chip does not provide an Interrupt. Correct?
So I'm assuming the probe does not have its own IRQ pin and is basically polled. So firstly there is latency in servicing the ISR, then there is the time for a step to occur on the stepper, then there is the chance that the probe input is High when polled (because of bounce), abd there goes another time added to the number of steps before a probe touch is recognised by the software. So the more noise the deeper into the copper, the more time elapsed the bigger the error. Not having all these timming values makes it hard to pinpoint a fix. Also I may be totally wrong! 😉
Some more software enlightenment is needed to get to the bottom of this!
Cheers
Tom

@Mot007
Copy link

Mot007 commented Aug 19, 2023 via email

@tmr4
Copy link

tmr4 commented Aug 19, 2023

I get the same probe voltage with a multimeter. I have the Genmitsu 3018 ProVer V2. There must be some level conversion going on. It might be hidden in the probe. I haven't been able to find much information about it.

I think your understanding of the probe routine is correct. Here is the probe state monitor:

// Monitors probe pin state and records the system position when detected. Called by the stepper ISR per ISR tick.
// NOTE: This function must be extremely efficient as to not bog down the stepper ISR.
void probe_state_monitor()
{
  if (sys_probe_state == PROBE_ACTIVE) {
    if (probe_get_state()) {
      sys_probe_state = PROBE_OFF;
      memcpy(sys.probe_position, sys.position, sizeof(sys.position));
      bit_true(sys_rt_exec_state, EXEC_MOTION_CANCEL);
    }
  }
}

@Mot007
Copy link

Mot007 commented Aug 20, 2023

TMR4, are you able to tell me what processor your
Genmitsu 3018 ProVer V2 has and the version it returns via $i

@tmr4
Copy link

tmr4 commented Aug 21, 2023

Mot007, I haven't seen the specific processor listed, but the specs say it's a 32-bit ARM. $I returns [VER:ARM32 V2.2.20220826:] [OPT:VZL,35,254]

@Mot007
Copy link

Mot007 commented Aug 21, 2023

20230820_173436
The top trace is the probe input (trigger low)
The bottom trace is the Step pin on the Z controller. (Allegro A4988, Chinese version)
As you can see the stepper continues for several pulses after the probe input goes low. I did this many times and the pulse numbers varied. All I can think is that the GRBL software in the ISR ( which sets the call to the probe monitor) is skipping due to who knows what.
The mapping has improved after removing bounce from the input but I'm still getting wrong values.
A good Firmware person should be able to debug and fix this problem.

@Mot007
Copy link

Mot007 commented Aug 21, 2023

Mot007, I haven't seen the specific processor listed, but the specs say it's a 32-bit ARM. $I returns [VER:ARM32 V2.2.20220826:] [OPT:VZL,35,254]

You should check your probe wiring, and possibly 12V coning from the motor PS!

@tmr4
Copy link

tmr4 commented Aug 22, 2023

My z-probe has a three pin connector. The control board labels for these are 12V, GRD and Pb which I assume stands for probe. At the control board, the voltage of pin 12V is 12.6 volts and pin Pb 11.6 volts, the same as I measured previously between the probe alligator clip and ground plate. I don't know how Pb is driven; a schematic isn't available. The control board is in an opaque case.

I get the following if I power the z-probe separately at my workbench with about 12.5V in and Pb pulled up to that through a 1k ohm resistor, just because. The probe can't be disassembled for inspection.

SDS00031

The yellow trace is the signal I've shown before, between the z-probe alligator clip and its grounding plate. Here I've shown the alligator clip touching the grounding plate for about 280 ms. The magenta trace is pin Pb relative to GND.

The rise of the magenta trace looks similar to the bounce damping I was seeing before. If the alligator clip is left touching the grounding plate, the magenta trace rises to 0 volts after about a half second. This reverses when the alligator clip is raised.

I could not cause a bounce during these tests so I'm not sure how the magenta trace responds with that.

I want to look at the z stepper signal as well. It seems like a cause for the variability you're seeing. Unfortunately, I won't be able to work on this for a couple of weeks.

@Mot007
Copy link

Mot007 commented Aug 23, 2023

Here's more food for thought. From Google.

Usually, the surface of the conductor in printed circuit boards is intentionally roughened to enhance the adhesion to the prepregs. Typical surface roughness Rz of the copper foil commonly used in printed circuit board is 6 μm
🤔

@mar0x mar0x mentioned this issue Feb 11, 2024
Open
@poes8943
Copy link

poes8943 commented Feb 11, 2024 •
edited
Loading

copied from #626
test steps using Z-probe control button:
push Z-probe control button and perform a Z-zero after that (work coordinates now at 0.000 0.000 0.000)
jog Z-up 0.5mm and pushing Z-probe control button again (Z axis work coordinate at 0.399 now)
jog Z-up 0.5mm and pushing Z-probe control button again (Z axis work coordinate at 0.807 now)
jog Z-up 0.5mm and pushing Z-probe control button again (Z axis work coordinate at 1.199 now)
... there seems to be roughly an error of 0.4mm after each step and values adding up
... looks to me like there is an additional 1/10 turn of the spindle(?) (0.4mm)

same test with manual commands:
push Z-probe control button and perform a Z-zero after that (work coordinates now at 0.000 0.000 0.000)
jog Z-up 0.5mm and executing 'G38.2Z-2F10' (Z axis work coordinate at 0.009 now)
jog Z-up 0.5mm and executing 'G38.2Z-2F10' (Z axis work coordinate at 0.006 now)
jog Z-up 0.5mm and executing 'G38.2Z-2F10' (Z axis work coordinate at 0.007 now)

@Hostaler Hostaler mentioned this issue Feb 11, 2024
Open
@Hostaler
Copy link

Hi Denvi, Many thanks for a great piece of software. I'm using Candle 1.1.7 with a Vevor 3018 CNC mill to mill PCBs.

I undertake a height map before any PCB mill, and tick the box in Candle to use the map, but I'm finding that the height map doesn't seem to be providing the height corrections that it should. The cutting tip (0.1mm, 30deg) cuts down through the copper layer in some areas, but then only cuts part-the-way-through, or not at all, in others.

I decided to check the consistency of the height map process, and ran 10 consecutive height maps over exactly the same area (10 point x 10 point, height map probe feed =10), and looked at the .map files these runs created in Excel.

I've been concerned to find some dramatic and variable differences between the (what-should-be identical) height map coordinates.

I selected the first (of 10) height map as a reference, and then subtracted each subsequent height map array from the reference, and looked at the resulted difference arrays.

These different height map arrays showed fluctuating differences, both in their magnitudes and distribution. While most deviations fell in the -30 micron to +30 micron range (still surprisingly large, considering that the copper layer on a 1 oz PCB is 35 micron), several difference maps showed some points that were 200 to 900 micron deviant(!).

These latter figures are clearly in error, but it seems they all might be, as no two deviation arrays were the same. I would have expected to see typical machine and randomisation errors of 0~5 micron, perhaps, but not 20-30 micron, and certainly not 200-900 micron.

Could I ask your comment on what you think may be happening here? I can send the Excel file with the height map difference arrays, if it's useful.

Many thanks for your help, Glen

How do I apply all this so as not to lose precision?

@Hostaler
Copy link

How do I apply all this so as not to lose precision?

@Hostaler
Copy link

Hostaler commented Feb 11, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests