Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: adprinter on September 01, 2019, 12:55:10 AM
-
I designed and built a 4 axis router table. (Basically a mill table, with 4th axis functioning as a lathe). I purchased the Mach3 software with LazyCAM Pro, and have been running the machine since 2008 with few problems. However, lately I have been experiencing things that I cannot seem to pin down. About my machine:
48vdc Keling Technologies power supply to a Gecko G540 driver. All motors are NEMA 34 steppers wired in Bipolar Parallel configuration. I use CorelDRAW to create most basic tool path artwork, and export the files from Corel DRAW as Hewlett Packard Graphics Language *.plt files. These files are then imported into LazyCAM, and edited for tool path creation. Most files of this type are used to engrave wood carvings that I do (using MeshCAM Art software). However, something is causing the X axis to "Drift" during the engraving process. I have tried cancelling all G41 or G42 moves (so that the tool path follows at center line with No cutter diameter compensation), yet the problem persists. The artwork is a simple arrangement of lines and arcs which form the letters in the word "Lieutenant". The letters are arranged in an arc, and engrave with absolute precision and repeatability with the exception of the letters T and E near the center of the arc. The vertical lines of those two letters seem to "step over" approximately 0.050" with each pass of the cutting tool. Obsessed, with finding the cause, I filled in the damaged areas surrounding those two letters with wood putty. Then re-homed the machine, and tried it again. The cutter followed the existing cut lines with absolute precision. And repeated the "step over" on the vertical lines of the T and E AGAIN! I have checked the G code, line by line, and there does not appear to be any variation at all in the starting and ending coordinates of each of those vertical lines. The G91.1 code is inserted by LazyCAM due to the single arc that appears in the letter U. The only other G codes that appear in the file are G0 and G1. So, I am baffled. I can upload the gcode file so others may inspect it for themselves. The specific size of the area to be engraved measures 7.5" wide x 10.75" tall. The zero coordinates are at center (X3.75 Y5.355) the cutting depth starts at Z-.4200" and cuts to a depth of Z-.452" The tool I am using, is a 1/8" diameter engraving cutter which features a very sharp V cut which measures about 0.02" wide at the tip, and flares out to about 0.025" at the top. (Relative to the depth of cut). It would be great, if someone else could do a test cut of this file, and report whether or not the letters engrave correctly. The attached Lieutenant.tap file is the one I am referencing here. Any advice, or suggestions as to the possible cause is greatly appreciated!
-
Your Gcode runs just fine here - there is no misalignment of the T & E characters.
(You may like to take a look at the free software 'F-Engrave' it will certainly create a better toolpath than the HPGL you are currently using).
Tweakie.
-
Thanks for that, Tweakie. "F Engrave"? tell me more. I have been painstakingly using LazyCAM for years, and having to manually re-order the cutting order of each line of each character in order to force the machine to engrave in the same manner it would do if it were actually text. The reason being, that while text can be engraved, it always comes in as an outline of the characters. Which is fine, as long as the desired characters to be engraved are a minimum of 1" in height. But rather useless, when the desired characters are only 1/8" in height. The double-lines created in a character outline tends to result in an unrecognizable hole being drilled into the wood.
THANK YOU for trying the G code, to verify that it is correct! I am still no closer to diagnosing the problem. The tool parameters for the engraving bit, takes .008" per pass. So, with a starting depth of -.420" to a cutting depth of -.452" it actually makes 5 passes per character segment line. As you can see, in the photo of the actual engraving, the vertical lines of the character segment of the center T and E letters, seem to be "stepping to the left" with each pass. This is ONLY happening with just those two letters. As you can also see in the photo, the repeated runs of the engraving has resulted in repeated engravings of ALL other letters with absolute precision! My thoughts now, are that perhaps the lead screw on the X axis has some sort of wear in this area, allowing machine vibrations to cause the router to "drift" from right to left, during carving. But again, WHY does it only happen in this area (which only measures about 1/2" to 5/8" wide)? Inspecting the lead screw, does not reveal anything, so????? Perhaps an excorcism is in order....
-
LC is an importer of ver 12 DXF files. How it does with other formats on importing I can't really say.
Take look at attached pic which is a backplot of your gcode posted into CAD.
You will see gaps on many of the text lines where they should terminate or join together.
For text that is not so good as you can see in red some of the pathing that is actualy being made.
There is a manual for LC and these kinds of comments are covered.
Also note that zero Y is 5.3750 and not 5.355.
Not sure that Corel Draw is an actual a vector drawing program.
The letters on the right were enlarged in CAD.
FWIW,
RICH
-
Thanks, Rich. After seeing the results that Tweakie posted, I started thinking that my problem is something mechanical. I have ordered a new lead screw nut for the X axis (since the existing one probably has somewhere in the neighborhood of 1 million miles on it). I tried slowing the feed rate to a crawl, so that I could witness the axis read-outs during cutting. There is no movement displayed which is outside of the coordinates in the G code. So my thoughts are: the excessive wear of the acme threads of the bronze lead screw nut allow machine vibration to cause it to move from thread to thread surface of the lead screw. This has been the DEVIL to track down, (and I am STILL NOT convinced that it is the actual problem), but thru trial and error (as always) we shall see....
As for LazyCAM's ability to interpret *.plt files, it has for over 11 years now. CorelDRAW version X3's DXF export results in a microscopic sized image when imported into LazyCAM. After experimentation, I found that the HPGL.PLT file format preserved the images in the actual size drawn, when importing them into LazyCAM. For engravings, in particular, I have created my own "Fonts" for use with the CNC. They are obviously NOT actual "Fonts", but just a vector graphic image of lines, circles, and arcs. I am aware, that the "Circles and Arcs" created in CorelDRAW are NOT actual ellipses, but rather a series of segmented lines which form the arcs.
However, for my purposes (engraving simulated "Text"), it has served me well for over 11 years now. Until I encountered this problem the other day. Hopefully the new lead screw nut will cure this problem (once it arrives). THANKS for your help!