[Dragonfly]

Yeah, I had to manually search/replace the plunge speed as 25 mm/min is too slow.
Also, another direction of expanding the program would be to save in some way the probed variables and read them back to set directly for a separate MOP on the same material.
I use a narrow profile pass to form the tracks with a very pointy bit and ensure track have minimal isolation and after that use one with a wider tip to clean additional copper. I had to combine both in one MOP because after the first cut the bit leaves some raised material along the paths and second probing will give wrong values at some points.
Using CamBam.

[MarcusWolschon]

G code doesn't allow to read or write files.
There's no way to persist the register values.

[Dragonfly]

Thanks, I was afraid this is the case but hoped there was a workaround

[lwill]

Yes, it is possible with Linuxcnc if using 38.x probing. If you look back one page the script I posted modified the original Etch Z Adjust code to do that. It can write values to a log file that can be read back in.
I have made a bunch of changes to it, like the ability to convert front side and stencils as well, and made it all into one giant script. Still working bugs out in over 3300 lines of python.
Since there was never any comments about it I never bothered to post an update.
Since I only use it every few weeks, I get it working 'good enough' for me, but each time I seem to find something else to add or fix, so I still don't consider it "stable".
If I can get a few more bugs out I will post an updated version if there is any interest.

[Dragonfly]

I am using Mach3. Have LinuxCNC installed but not so familiar with it. It can be done actually in Mach3 using its scripting language but I have written only simple scripts and do not know the internals so deep.
Marcus' Java application on the other hand does its job nicely the only setback being inability to save and use saved surface data. But there are workarounds.

@Marcus
Seems I discovered a bug. When there are long straight moves the app tries to break them into smaller segments for height adjustments and simply hangs. Or maybe I didn't wait long enough?
I wanted to make a narrow and long PCB - 32 n 154 mm and defined a pocket OP to clean the unwanted copper which produces long moves from one end to the other at the same depth, i.e. there are only two points at start and at end of the tool path. These cause the hang. Without them everything is fine.
ATM I am thinking about a way to break them into shorter moves.

[MarcusWolschon]

I'll have a look. (but not right away, busy)
If you find it first, feel free to send a pull-request on github.
I did test that subdivision and it worked on my PCB but maybe there's something I missed when start and end are at the maximum/minimum coordinates or something around 0 or with negative coordinates.

[Dragonfly]

I'll try to find the exact occasion it happens. When looking into the generated file there are several subdivisions (commented) but at some point the program has stopped. I'll try to see why.

[Jay C]

I tried your software this past weekend Marcus, I got an error message from Mach3. "Line too long"

This is the offending line at the top of my modified gcode file:
(Inch Mode)
G20
(Absolute Coordinates)
G90
G00 X0 Y0 Z[17976931348623157000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 000000000 + #3 + 1*#104 + 0*#109]
M03
G04 P0.000000

Is it a bug?

Here is the original Gcode:
(Inch Mode)
G20
(Absolute Coordinates)
G90
G00 X0.0000 Y0.0000
M03
G04 P0.000000

[MarcusWolschon]

I added yours as an issue:
https://github.com/MarcusWolschon/PCBZCorrect/issues/1

Already fixed in source code.
Not having any Z coordinates was not anticipated.

[Jay C]

My Java is rusty, do you mind recompiling the .jar file with the fix? In the meantime, I'll try to wake up some brain cells.

Thanks,
Jay

[Jay C]

My Java is rusty, do you mind recompiling the .jar file with the fix? In the meantime, I'll try to wake up some brain cells.

Update: I installed JDK 1.7, installed WinAnt and recompiled new source. Still the same issue/result. I have attached the PCB-Gcode output for the bottom etch layer for your inspection.

Thanks,
Jay

[MarcusWolschon]

Sorry, forgot to push my changes to the server.
There's now also an new executable jar and the plunge-speed parameter is added to the g-code (no graphical input).

[Jay C]

Update: I needed to make some updates to the build file to add in the compiling so that the Main.class file would reflect the changes. The fix #1 works.

Here is what I am using for the .build file for Ant

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project name="PCBZcorrect" default="run" basedir=".">

<!-- global properties for this build file -->
<property name="source.dir" location="src"/>
<property name="build.dir" location="build/classes"/>
<property name="doc.dir" location="doc"/>
<property name="main.class" value="biz.wolschon.cnc.pcbzcorrect.Main"/>

<target name="clean">
<delete dir="${build.dir}"/>
</target>

<target name="compile">
<mkdir dir="${build.dir}"/>
<javac srcdir="${source.dir}" destdir="${build.dir}"/>
</target>

<target name="jar">
<mkdir dir="build/jar"/>
<jar destfile="pcbzcorrect.jar" basedir="${build.dir}">
<manifest>
<attribute name="Main-Class" value="${main.class}"/>
</manifest>
</jar>
</target>

<target name="run">
<java jar="pcbzcorrect.jar" fork="true"/>
</target>

</project>

-Jay

[MarcusWolschon]

Yes, it builds in eclipse.
The Ant build.xml was just to create that executable jar.

[Dragonfly]

Hi Marcus,
this is a line from the console when an exception was thrown.
-1.9984014443252818E-15=lastX(0.259999999999998)-minX(0.26)
Note the underlined value. For all practical purposes it is a Zero.
I am using CamBam for G-code generatiionand and have similar issues there due to the same kind of values which are in fact zero.
So maybe the problem is not in your code but in the values CamBam writes in the G-code.
I modified your code to check if the absolute value of xlength and ylength is less than 1/1000 of a mm (absolutely enough for real world work) and set them to zero if so.
The problematic .nc file was parsed normally this time. I am so rusty with programming and my intervention is not elegant though.
I am using NetBeans IDE and made a new project using your source. Have forgotten almost everything about NetBeans but somehow managed to build an usable .jar file.

[MarcusWolschon]

Sounds like we may habe found für issue.
Can you make pull requests on GitHub to get your code change commited vor shall I apply a patch?

[plutonn]

Hello MarcusWolschon, I am testing your script with mach3, the version 1 no working fine, the mach3 have problem "command too longline". I have downloaded the new version2 but i have a diferent new problem. i can´t use unit "mm", i put to mark in the box "convert to metric (if needed)" but the file is empty.
I hope your answers.

Regards

[Dragonfly]

Hi Marcus,
I am not familiar with GitHub so I'll post a code snippet with the changes I made, they are really simple:

	private static String getInterpolatedZ(double lastX, double lastY,
			Rectangle2D max, final int xsteps, final int ysteps) {
		// bilinear interpolation
		double xlength = lastX - max.getMinX();
		double ylength = lastY - max.getMinY();
		double xstep = max.getWidth() / (xsteps - 1);
		double ystep = max.getHeight() / (ysteps - 1);

                if (Math.abs(xlength) < 0.0001) {
                    xlength = 0;
                }
                if (Math.abs(ylength) < 0.0001) {
                    ylength = 0;
                }

		if (xlength < 0) {
			throw new IllegalArgumentException("xlength(=" + xlength + "=lastX(" + lastX + ")-minX(" + max.getMinX() + ")) < 0");
		} else if (xlength > max.getWidth()) {
			throw new IllegalArgumentException("xlength(=" + xlength + "=lastX(" + lastX + ")-minX(" + max.getMinX() + ")) > width(=" + max.getWidth() + ")");
		}
		if (ylength < 0) {
			throw new IllegalArgumentException("ylength(=" + ylength + ") < 0");
		} else if (ylength > max.getHeight()) {
			throw new IllegalArgumentException("ylength(=" + ylength + ") > height");
		}

I finally set the comparison value to 1/10 000-th just to be on the safe side.
I also changed the size of the dialog window - made it wider but shorter, because on a smaller screen it fills it top to bottom.

However I found another problem - long arcs (G2 and G3 commands). Short arcs are not a problem but the PCB which raised all those issues has almost circular tracks around 70 mm in diameter. The G-code uses 3 arcs to make the track outline and the X/Y moves are relatively long from start to end. The program tries to break the moves into shorter ones, using the same I,J values. As a result funny tool trajectories appear
One workaround is to break the long arcs/circles into tiny line segments in the CAM program or to smaller arcs if the program is capable of it.
Anyway I think it would be appropriate to add into the program a check for G2/G3 commands and if the arc requires braking, issue an error message. This would be an emergency solution. I haven't thought and have no idea is it possible to break arcs accurately within the program.

Regards.

[MarcusWolschon]

I wrote it for pcb2gcode.
I don’t know any real CAM programs that can do PCBs.
What program created the g2 and g3 codes?

[Dragonfly]

As I wrote, I'm using CamBam.
I make the PCB layout with DipTrace, export to Gerber format and open it in CamBam, Its interpreter makes smooth curved polylines and in actual process the router tool moves smoothly without the jerking and shaking which occur with numerous tiny segments. However, I can convert arcs to small straight segments within CamBam, having control over the desired precision.

BTW, DipTrace can export to DXF with a set tool tip width offset and user determined number of passes to achieve the desired insulation width.