Ergoman:
"My question is: Do you do much pocketing and offsetting of your drawings?
... If you can get usable offset and pocket paths, I'll give 2.47 another shot."
I have been successfully using pocketing but it really requires jumping through multiple hoops to get reliable G-code output.
I have created a DXF design with multiple pockets within pockets that (ideally) requires 13 total chains. LazyCam 2.47 simply
can not handle this in any reasonable way. Note that LazyCam 2.55 works FAR better on this design, but it still can't handle
it correctly. Using "Clean: a large number of times results in LazyCam toggling between perhaps 3 unique results, 2 of which
are completely worthless (diagonally located distal segments are being stitched together rather than proximal segments) and
the 3rd result is much better - but still totally useless. To get LazyCam 2.47 (and 2.55) to handle this design I split it apart into
7 DXF files, with only immediately adjacent chains being in each file. This reduces the complexity to only a single outer and
1 to 4 immediately inner chains, with no more than a single level of chain nesting in each file.
Doing this and then pocketing with LazyCam resulted in the largest file being 2MB in size with about 60,000 lines of G-code.
The next largest file had about 40,000 lines of G-code and the remaining 5 files were much smaller at a few thousand lines
each.
However, while the resulting LazyCam pocketing for each of the 7 patterns looked fine within LazyCam, importing them into
Mach 3 showed that there were numerous circular path artifacts that were not visible in LazyCam. These extra circular paths
would destroy the resulting machined shape, since they cut channels that were not in the design. The nature of these extra
circular paths was identical to when you manually move the starting point of a circular arc within LazyCam such that the two
endpoints of the arc cross over. i.e. A small circular arc of +15 degrees turns into a circular arc of -345 degrees due to the
start point crossing over the end point and the arc gets generated backwards relative to the original intent.
To locate these few dozen extra circular arcs within the G-code file I edited the G-code text while moving through the G-code
with Mach 3 by using the scrolling button capability on the right side of the Mach 3 G-code display window, while examining
the 3D plot. As you step through each G-code line the current segment lights up white in the 3D display so that you can fairly
quickly scroll through (in this case up to 60,000 lines) to get near the offending path and then single step by using the up and
down arrows on the scroll bar until the bad path turns white. Reading the G-code line number allows you to go to that line with
the editor and then you need to perform a search on the line contents (ignoring the embedded line number) to delete all of the
occurrences of that line. You will get multiple occurrences of that line whenever the pocketing requires more than one pass to
get to the final depth.
I also noticed that there were a HUGE number of unnecessary Z axis moves which greatly slows down the machining. I was
able to remove these by manually editing the LazyCam G-code output file. Believe it of not this alone reduced the machining
time by more than a factor of 2X.
So, by doing all of the above I was able to generate and then manually clean up and get reliable G-code files for this design.
My testing indicates that the Clean function is using a deeply flawed algorithm for stitching together segments (entities) to
form a chain. It usually takes one or two dozen successive “Clean” operations to get to the best, but not necessarily correct,
chain formations. Correct chains would be doable with only a single “Clean” operation with a robust algorithm. The fact that
Clean toggles between better and worse chains and converges very slowly to most often an incorrect result indicates that it
needs serious work. I say this as someone who does specialized image processing involving data files exceeding 100 GB
in size.
If any of the LazyCam developers want a copy of this DXF test file, I am willing to email it - since it apparently represents
something that exposes a number of LazyCam flaws. Likewise (since I have a vested interest) I will provide free algorithm
support to any of the developers for making LazyCam more robust. It is currently a good start, but I would personally call
it as being in alpha phase rather than beta phase.
Additional useful LazyCam features (which should not even be considered until it is made much more robust) would include:
1. Using the same mouse/keyboard keys for 3D display zooming, panning, and rotation that Mach 3 uses. Currently, it
has some differences.
2. Recognizing that some of use use trackballs instead of mice. The “inverted mouse” trackball makes many operations
easier but some of the simultaneous mouse button pushes are made more difficult because you may not have free
digits left over to move the ball.
3. Generating an estimated total machining time for the operations being performed. This should be very easy to do
since LazyCam knows all of the paths and their respective velocities.
Guest
