Messages

51

LazyCam (Beta) / Re: lazycam

« on: August 05, 2006, 09:11:37 AM »

Brian, check out Mytmill by acumotion.  Not nearly as good as your LZ but a few interesting features in the G code output.  One option allowes the user to select allowed mismatch in line ending for "blending" .  Another is segmenting toolpaths in the output with labels to improve understanding.  LZ is much better already but MyTmill has a few neat feature to look at.

52

G-Code, CAD, and CAM discussions / Re: G42 problem

« on: August 04, 2006, 09:17:07 AM »

Now i see the advantage of the 45 and arc type leadins as opposed to the straing in.
Never to old to learn soemthing new.

53

G-Code, CAD, and CAM discussions / Re: G42 problem

« on: August 03, 2006, 06:39:57 AM »

Your right I did not understand how it worked.  as they say a picture is worth a 1000 words.
thanks.  Should the last cut then remove the small angle since it is going back to the center of the green circle? 

54

G-Code, CAD, and CAM discussions / G42 problem

« on: August 01, 2006, 12:18:40 PM »

I posted this on the lazycam forum but i think it may be more of mach 3 issue.  Attached is a tap file created with LC latest release.
When i run this file using a .250 cutter in tool #1 the cutter is weird at the leadin area.  It appears there is an issue right after the G42 command.  It appears that Line 60 and 65 combine instead of 60 completing before 65 starts.  As the leadin finishes there is a slight angle as it moves to the tool path.  It does not make sense because according to the code it should not combine the too moves.  If it did the angle would be the entire length of the first compensated toolpath. 

In my first post i recieved a reply from someone (ger21) telling me i had not put in enough information for tool # or tool dia but that does not seem to be the issue.  The file runs fine from LC except for this one issue.  I tried modifying the code file with that Ger21  suggestion, still same problem.  I also tried this with other leadins and with version 90.60 still same issue.

Am i nuts or am i doing something wrong.

LZ postion is also about g42 problems about #3 down the list.

55

LazyCam (Beta) / Re: g42 has a Problem

« on: July 27, 2006, 01:23:53 PM »

I had not seen a problem either until lately. 
The gcode file as processed by LZ works except for appearing to combine lines 60 and  65 into one move.

I had often wondered why there was nothing in the cgode file to reference tool number or radius but the offsets look good in the toolpath display.  In  LZ I specificed the tool number (#1) of the cutter and have diameters loaded into M3.
If your testing tool #1 has a diameter of .250.

56

LazyCam (Beta) / g42 has a Problem

« on: July 27, 2006, 10:46:29 AM »

two things are on G42.
First when you generate a g41 or g42 you do not attach it to its own line number, See attached.

Second when i run the attached file the leadin does not work right.  Line 60 and 65 seem to combine instead of 60 completing before 65 starts.  Not a LZ problem but very strange.  Just loaded 1.90.65 this morning.  Probably in Mach3 not LZ

57

LazyCam (Beta) / New problem

« on: July 15, 2006, 11:40:54 AM »

Attached is my .Tap file (very simple) Gcode cause it to cut inside instead of outside.  What am i doing wrong.

58

General Mach Discussion / Just full of requests today

« on: July 15, 2006, 11:32:21 AM »

I'm not yet into screen designeing yet so i'll ask you.
On offest screen, the run program screen, or the toolpath screen or all when i'm dong setup is would be real nice to see the jog distance setting. also set distance or continious.   Basicall copy what is on the middle right side of the diag screen.   

59

LazyCam (Beta) / Reverse import of hole into LZ

« on: July 15, 2006, 11:22:43 AM »

I tried loading in an old .tap  from Mach3 to make soe changes (much smaller task) the reverse load into LZ did not bing the Drill points bakc in and they are lost. Can you check this out.

60

General Mach Discussion / Suggestion

« on: July 15, 2006, 11:17:51 AM »

I messed up a part today doing something stupid.  I'm hopeing you can help.
When i hit the "goto zero" inthe run program screen the x&y move started long  before the Z.  Braged across part broke bit etc etc.  Shouldn't the z move complete to a "safe" postion before moving the X&Y.  this may change based on which axis you define as primary move axzis.   Your thoughts