Hello Guest it is March 28, 2024, 05:25:06 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ART

1141
LazyTurn / Re: LazyTurn
« on: January 10, 2009, 12:22:31 AM »
Hi Guys:

  Ill keep simulation time in mind, shouldnt be too hard to arrange since I know the feedrates and how many lines..

Still working on stock profiling of the cut to the tool.. :)

Art

1142
LazyTurn / Re: LazyTurn
« on: January 06, 2009, 07:16:57 PM »
Hi
 post modification variables like indeed rates and such can be added later.

Art

1143
LazyTurn / Re: LazyTurn
« on: January 05, 2009, 12:45:28 PM »
Hi:

 If ann.dll is not found, then you havent installed the LazyCam update before trying LTurn. Download the LCam update file and install that first.

thx
Art

1144
LazyTurn / Re: LazyTurn
« on: January 05, 2009, 10:56:35 AM »
Hi Guys:

 Well, after a detailed analysis of the finish pass requirments, Ive decided I cannot cheat by using rough pass information to trace endpoints or anything.. seems the only true path to sucess is to
do it properly by computing whats actually cut on each pass so we have a stock removed database.

  This will take me awhile, I have to divide each tool down the center so I can subtract it from the slid at start and end of path stretched across the linear path.That will give me a proper
profile of whats removed, and what isnt. From there I can do simulations and calculate a proper rough/finish and finish pass. So Ill start that now and see how it goes. Sounds tough, but it may
turn out to be easier than I think. LazyTurn is actually working each step much like a manual usage of the lathe, so its best I think to continue down that path and let it do each step properly, the finish
will then be better and more accurate. Back to you when I have a new version that displays material removed. Ill work on the assumtion that each tool can cut on both sides and will leave tool side gouging till we have material removed database up and running.

Thx,
Art ( Just keepign you informaed.. :)  )

1145
LazyTurn / Re: LAZYTURN MANUAL
« on: January 04, 2009, 05:10:23 PM »
Rich:

 Just read the manual , great job!. Ill be adding you to the credits in the program as well. Dunno if that will giev you Fame or Blame.. ..but thats software for you. :)

Art

1146
LazyTurn / Re: LazyTurn
« on: January 03, 2009, 11:51:12 AM »
Hi Guys:

  As you can see from Willems letter many tools would be a problem in terms of computing a gouge free path. Im thinking direction gouge capability is looking better and better. I do like the idea of simply using the roughing end points as the finish path computational points though, makes sense only if the finish tool IS the roughing tool though.. hmm, but if I fake a rough based on finish tool, then use the endpoints of the rough to determine the path of the finish... that sounds liek somethign Ill investigate, dunno if thats what you meant but its a great way to get the data independant of doing an actual path removal process.. that way I only need a tirtiary gouge process based on tool cutting side definition.. Gotta think about about that one.

  As to simply backing off to the previous rough end point on the passing that woudl create collisions in any udercut zone. I like what Ive read though, its given me some idea's.. I think Ill spend some time investigating using just the roughing end points to generate a finish pass.. all endpoints should be legal, and I should be able to convert equi-radial points to arcs.. interesting.. but I think Ill hit some bad arcing issues based on the collision changes not reflecting the true arc of the profile.. but then maybe I can use that to better define the rough stage.. hmm..

Art

1147
LazyTurn / Re: LazyTurn
« on: January 02, 2009, 06:44:52 PM »
HI Guys:

 Thx, Telling me you dont understand the issue is a valid feedback, it gives me an idea of just how Lazy I have to make it all, the reason there is interest in Turning software isnt just the price of available software is high, its that the software that IS available is pretty complex to use, and requires more understanding than most have of the complexities of turning. If, in the end, LazyTurn is limited to certain types of turning, or allows for a person to get comfortable enough with turning to move upwards to other software, it will have lived up to my initial planning.
   All that having been said, Ill try to make it work for most things, but to me the most important is to try to make it easy.. few button presses and fewer options. Its my holy grail on this project, Im quite willing to tell the "My tool is shaped like an octopus tentacle, how do I turn an inside bore with exclusions?" user to get a copy of the high end stuff, I really just want the causal lathe owner to have some entry level power that may be enough for him/her.

  Of course, being a casual lathe owner myself helps in that, I truly dont know wtf Im doign half the time or more on a lathe, so the work so far reflects what I tend to think I personally want from a DXF->Turn convertor. LOL

Art

--Incompetance is an Art.. I'm mastering that "Art".

1148
LazyTurn / Re: LazyTurn
« on: January 02, 2009, 03:28:42 PM »
RC:

  Unfortunately, its become a design fork.. Take the problem the other day, where the tool doesnt keep on cutting inwards on the right angle, this is due to only sensing gouging on the profile,
not on the stock previously removed. I have tried to think up a finish algorithm, BUT, the math is impossible unless I know whats previously been cut. I cant just follow the profiel because some would
be impossible without sensing the impossible area's of the previous roughing stage.
  So it seems Im stuck with having to do a "material removed" algorithm instead at this point so I can sense when the tool colides with the stock itself on a non-cutting edge. Till now we've been assuming all tools can cut on both sides, a bad assumption to make.

  BUT, I want to keep it lazy as possible. Wether a tool can cut on both faces or not, and how much it can cut on the opposing face is something very few users woudl find easy to define. As it stands, the Left/Right/Center tool tip to holder relationship is not used in reality, it just allows a user to see the tool matching theirs easier. However, if I use that information to make the decision about what parts of the tooltip are a collisiion, and what parts are actually cutting , then perhaps I can more easily write a stock removal process, so as the cuts are performed we're left with a stock chopped down properly. This "left-over" stock profile is what can then be used to make a finish pass, and woudl also allow the proper angle to be done for the non-cutting side of a tool not to gouge. This is similar to the very misunderstood "BackAngle" setting in LazyCam and other programs. its actually a line drawn back from the tip to the non-cutting side to stp gouging of the holder or non-cutting side of a tool into which the profile will not be allowed to gouge. This woudl limit undercutting ( which is why many programs dont allow undercuts.).

  The decision thats made will set a not too easily changed direction in the code. So I have to make the right one. Looking at all the holders available, inserts available, not to mention home-ground tools that can be made, Im thinking this is a very critical decision in terms of the limitations each path will put on subsequent code and how it works. You can actually generate any tool shpe I think as left,right or center tools, so Im thinking the decision as to what direction to cut, as well as what side of a tool doesnt cut, may be easiest as a defined Left cuts Right, Right cuts left and center cuts either side type of rule setting. This means in essense that a Left cutting tool woudl not be allowed to gouge more than the tip radius on the right side of the tip 0 point, This woudl keep the angle proper in the example posted earlier this week. The assumption that a tool can cut on either side is likely to bite us hard in future, probably best to deal with it now.

 So think about it if you understand, ask me more if you dont so we can decide this as a fucntion of what needs to be done and how it will affect future code and limitations. I dotn think we want tool decriptions with pages of paramters little understood and often misused. ( LazyCam syndrome :) ). To me, by forcing direction and gouge detection style to left/right/center selection, it makes it more automatic and probably easier to make up a tool that although it doesnt really look like the tool actually used, it works as expected in terms of the end toolpath. This is a very hard one to explain fully, but its come to the point I realise I cannot do a finish profile, not even a simple one, till I have made code to simluate stock removal, and the cutting edges are now very important

  If anyone doesnt understand this question, I suggest they look carefully, and you all discuss it, if I make the wrong decision it could be a very lagged development as we go backwards to correct it.  We're at the stage things are loading pretty good, though Im sure I can tighted up a few things to make even that better over time, and to move forward further requires the stock removal process to be done. Then a proper finish path can be calculated. ( I think.. LOL ).

 Thx
Art


Art

1149
LazyTurn / Re: LazyTurn
« on: January 02, 2009, 01:54:00 PM »
Hi Guys:


  My personal though is that I may have to respecify tools.. A center tool will be considered to cut on both sides of the tool, a right only on the right side, and a left tool only on its left side.

Soemhow I have to deal with the problems of gouging a tool on its non-cutting side.. does the above sound like a proper solution. This means left pointing tools woudl only cut right to left,
right tools woudl cut only left to right, and center tools woudl default to right to left, but will be considered as cutting on either side of the tip..

Art

( Just thinking..)

1150
LazyTurn / Re: LazyTurn
« on: January 02, 2009, 11:43:32 AM »
Thx.. 

 That does seem a clipping issue rather than a inside/outside one. The rate this program is proceeding is directly due to all the work you guys have done on the dxf analysis, its really helping me. Just a note to say I truly appreciate it. Youve saved me dozens of hours of debugging. Way to Go!

Art