LazyTurn

[ART]

Rich:


  Exactly.., in your case youd make a small button tip with a holder of very small width. It isnt that the end tool has to look
exactly like the actual tool, it just has to reflect the actual cutting limitations you need, since you know that inherantly
the tool you use will not colide with the end balls, youd just use the afore mentioned tool description, and all shoudl be well.

  On the other hand, if you were roughing, you may want to describe a wider holder so that the ball ends will collide, and thus wont be cut
during the roughing operation, thus leaving the ball ends to be cut by your small holder tool description. You get the idea fine I think..

 ( All this is in theory of course, you just never know where we'll actually end up after all things are considered.

Art

[ftomazz]

  There already is G41/G42 in Mach3Turn, but unless one understand all the tip directions, tip radius, X and Z offsets very well, ( and is brave) I woudlnt use it. Its a tough thing to use. SO LazyTurn will  take the tool into account and generate code for that tool, with radius precompensated so the output code will produce exaclty what it says it will.

But the G41 ang G42 are working now? or they are only present on the tool table ?
I read before that they still are not implemented. If they are, then Mach3 is perfect for me!

Thanks

[Overloaded]

Trying to set-up 2 diamond tools, one angled left and one angled to the right. The angle is exaggerated for illustration.
+ and - in the angle select box evidently is one direction or the other but watch as the tool rotates. The insert is always on the top. At first I thought the holder was sweeping 180 deg. left and right but it looks more like it's rotating with the insert always in view because the angle direction of the insert reverses each time around.
Question is:  Would a pos. angle entry be to the left...like for facing or turning towards the chuck ? (right hand tool)
And a neg. be for back facing or turning away from the chuck ? (Left hand tool)
Load the attached example and watch it spin. Warning: It may give you a headache.
Thanks,
RC

Quote ART  "The tool will stop turning soon, and just have an option to rotate it , I just wanted a user to be able to see height as well as direction a bit better."

[ART]

Yes, thats what Id use rigth and left for. The only important thing is it matches the actual tools boundries as close as you can manage.

( G41/G42 are implemented, but very hard to use and untested for a long time. LazyTrun will put out precompensated code.

Art

[ftomazz]

( G41/G42 are implemented, but very hard to use and untested for a long time. LazyTrun will put out precompensated code.

Art

Mach should manage the G41 and G42 by itself in my modest opinion. This would give the user the possibility to chose the program that he/she wishes or to program manually lines of code. Also it would make mach3, more a more complete program, since lazycam is not "shipped" with mach3.
I understand that implementing G41 and G42 is a difficult task, but probably not so difficult compared to the creating of a precompensated toolpath that you will implement in lazycam.

[W.Jansen]

Hi RC

Funny, i get a different vieuw with the same settings.
watch the tip go in the other direction.

Greetings:
Willem

[ART]

>>Mach should manage the G41 and G42 by itself in my modest opinion

  The problem with g41 and g42 is they dont take the holder into account, nor the tool geometry really, they refer only
to the actual tip radius compensation, which makes them good on some things, not so good on others. Collision detection
is not possibel with g41/g42, since nothing is known about the tool other than the tip radius.. its more powerfull to create the
path precompensated, which si why most use precompensated code, not G41/G42 when they have a choice. End cut angles, side cut angles, back angles.. none of them make a difference in G41/G42 so the cut is actually much harder to do using comp in a controller , than from cam.
  The proof of that is simple, G41/G42 has been in turn for 3 years, no reports of problems, even though I know they exist. This means
noone uses them even if available. Everyone I have done support for uses percompensated code.. its always easier to do so..
( Personally, I find G41/G42 near useless in a controller for lathes..)

Art

[PaulWC]

HI Guys:

OpenGL errors are likely due to old openGL implementations, I tend to use new ones, so update video drivers if you get openGL errors, they may be caused by video card drivers not likeing some OpenGL lighting modes.

 The toolholder is as yet still rough, it will be made to conform more to the user in the future, and yes its shape will be taken into account for the generation of the Gcode in the end.
 The tool will stop turning soon, and just have an option to rotate it , I just wanted a user to be able to see height as well as direction a bit better.

( Graham: Does a grooveing tool have an X offset? OR a Z offset? I would have thought that a groove tool ( or cuttoff) woudlnt have an offset, or is the grooving tool actually having a rounded tip with , therefore, both a Z and X offset? The REd dot on the tool is the center of tool radius, from which the Z and X offsets are taken, but Ive never actually used a grooving tool so I wasnt sure if the tip had a radius or was simply a square edge...thereby having no offsets.. )


Thanks
Art

Durnit!!! I also get the OpenGL error... and have one of those Dell Dimension 2350's with on-board Intel graphics... no support for OpenGL 2.0 or 2.1. Can't afford a new computer, or even new mother board for now. Installing a PCI video card seems to baffle many before me that have tried. Oh well, the errors are just annoying, but cheap. ;o)

Here is the grooving tool I use:

http://www.use-enco.com/CGI/INSRIT?PMAKA=422-2880&PMPXNO=7908821&PARTPG=INLMK3

For profiling, I use the full radius insert at 0.078" width, 0.039" radius, 0.235" length:

http://www.use-enco.com/CGI/INSRIT?PARTPG=INLMKD&PMPXNO=3008017&PMAKA=990-1551

I have been using a custom defined button tool (diameter and length) in CutViewerTurn for proofing code, and has done pretty well, except when the tool holder body starts hitting the stock. It would be nice to be able to define the tool holder, which has a negative rake style front profile. It's a real gotcha when the same profile is applied to a larger radius part, and the bottom edge of the tool holder starts to "burnish" the work!

May do some creative relief grinding...

Paul, Central OR

[DennisF]

Hi Guy's
Just checking in is L-turn working and can i downlaod a version.

Dennis

[Overloaded]

Hello Dennis,
Download at reply #100, this topic.
We're up to the tools, but not finished yet.
Coming along nicely though.
RC