still no joy,
               mick.

Try putting the 3 files into the Mach3 folder NOT the lazyturn sub-folder.

Works for me that way.

Liking the new tools Art, can't make any sense of the button tools though.

On the grooving tools can we have a front and back edge offset, that way position and width can be compensated for.

Graham.

thanks Graham,
                     works for me to.
                                                  mick.

Hi Art

I get an opegl error.
Although it looks fancy but could you make the tool stand still?

Greetings:
Willem

Hi Art

Could you make the tool icon (in the white box) the real tool shape (tooltip in the yellow box)?
If i ask the impossible please take note that i have absolute no idea how difficult it is to make dose bits and bytes do what you want.
Is it possible (in the future) to edit the shape of the toolbody and that Lazyturn take note of the shape to calculate the toolpath?

Greetings:
Willem

HI Guys:

  The Icons are set bitmaps, so its hard to make the icon match, ( not impossible but best left as housekeeping after functionallity..)
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

Hi Art,

the way to do grooves is to use 2 offsets, for example if we use tool 7 we would use say offset 7 and offset 17, offset 7 would have a X and a Z offset for the diameter and the front edge of the tool, offset 17 would have the same X offset as offset 7 but the Z offset would be for the back edge of the tip.

E.G

Our tool tip is 1.5mm wide, we set our diameter datum as normal, we touch the front edge of the tip on the front of the job and set our Z offset, e.g. -100  The offset for the back of the tip would be entered into offset 17 as Z-101.5, that will put the back edge of the tip at the end of the job if we entered in MDI 'G00 Z0 T0717'

Man that's a lot of offsets 

The following code is what I would use to produce the drawing below.

N7 T0707 M8 (GROOVE 11.5*2)
(CENTRE TIP 1.5)
G00 X13.5 Z-4.75 G97 S750 M3
G01 X11.5 F.1 (CENTRE OF GROOVE)
G00 X13.5
Z-5.2 (USE TIP - FRONT EDGE)
G01 X12.5 F1.
G02 X12.1 Z-5. R.2 F.05
G01 X11.5 F.1
G00 X13.5
Z-2.8 T0717 (USE TIP BACK EDGE)
G01 X12.5 F1.
G03 X12.1 Z-3. R.2 F.05
G01 X11.5 F.1
G00 X13.5
X120. Z120. T0700
M1

Most grooving tools have a radius to stop them snipping the edge, the idea of the 2 offsets is to compensate for wear and maintain position. 

Graham.

Graham:

  Ahh, I think I see what you mean. My thought on the grooving tool is to still set a tip radius, this sets the internal 0 point of the tip, so the X and Z offsets are implied by that. In your example tool
then, if one specifed a tip radius appropriately, then the X and Z offset are implicit. So if you zeroed to the back edge of the tool, with no X,Z offsets setup , your actually changing the
side tolerances as well as the tip end. Though in your case that may not suffice. Ill look at that for you when I do a grooving tool sequence. We may have to have a dual offset, but as it stands ,( at least in my head) I think a general tool tip radius even for a groving tool should create the right offsets. ( Though zeroing may require a knowledge about if your zeroing to the left or right of the tool. ). But that I
expect may be true of any tool since tip radial center is the important setting for the tool. Not a problem in generation of code as direction is considered in terms of the cut, but zeroing will be the important
function in that regard. But Im not sure I see a differecne between the grovving tool or any other tip in that regard.

  I may be missing soemthing though, but Im sure it will become clear when you tell me I *********ed up on the generation for the actual code. , thats the point at which we'll find that problem. But for
actual code generation, motion direction will account for the path, zeroing I suspect is the problem in terms of setup.. On the other hand, if we just leave offsets to zero, and use a tip radius as the complete
setup in MAch3 for that tool. ( taking wear registers into account) , then really no offset should be necessary... hmm, gotta think about that one for MDI usage, my though was to eliminate the G41/G42 requirment by using tip center as the Gcode output default, thus making the output precompensated as to offsets other than tip radius.. Im still comig to grips with that internally though, so I guess
all I can promise is Ill fix that up as I screw it up.

 I can say that I had considered the zeroing to be semi automatic, since the code will assume the tip radius , then in MAch3, no offsets or G41/G42 shoudl have to be selected, when you zero to the X front of the stock, the zero will be assumed to be off by the tip radius in the X dimension, the Z dimension will have to be zeroed to the outside when a program is to be started, the asumption being that you have zeroed to the face and are now offset by tip radius in the Z ++ direction. The programs Gcode from LazyTurn will assume that when generating the code. Though perhaps a switch will be necessary to dictate to the Gcode poster that the true zero should be considered to be left or right. ( though the tool setup should be able to tell that in left or right sided tools.). Center tools woudl be the unknown
element. Youll notice a checkbox for "Use tip center", that will descriminate between using Mach3's offset registers with compensation, or just to create the code as precompensated using the tip radius as that compensation from tip center.

  As I say though, Im sure Ill see a dozen conflicts in there as I start to do all that..  so we'll discuss that in depth as I start to generate code. Ill be sure to structure it to give us some flexability there as I
know that my sad lack of turning experience will screw up my head in offset terms a bit as I go. We'll see how automatic I can make that.. but since Im generating the code, I shoudl be able to make automatic assumptions based on the direction of travel that a cut will do as you swap a tool on a zeroed system and continue the job using the original zero point from another tool.. So in the end, for myself
anyway, Id liek to get away from using offsets all together, and just use tip radius as the effective factor.

 By the way, there was a bug in the original release that made button tools not work, no tip was shown, that last download though shoudl show a button tip as a typical button tool, ( just a round disk with tip center at center of the button..

Art
 

Thanks for the reply, I look forward to the results of your labour, its going to be great.

Graham.

Hi.

One important thing that must not be left behind is the tool radius compensation. Nobody wants a cam software that will not reproduce the final object different from the drawing.
For what I read, I think that lazyturn will "translate" a dxf file or another input file into a gcode program. It will select tools, manage toolpaths etc, and mach3 will process the gcode file generated by it.


Now a question:

The toolpath generated by the lazyturn will be the exact piece and mach3 will manage the tool radius compensation

OR

Lazyturn will create a toolpath that already includes the tooltip radius compensation ?


My suggestion is that mach3 compensates the tool radius. In this way a user is free to use its cam software. For example I made a program to do just that, translate a dxf into gcode, but the final object differs because of the radius of the tools. I must draw it already thinking on the tool and make some calculations that is difficult and easy to make mistakes.
Also, I think that this feature already should be functional in mach before more work is pointed to a "turn utility", since it is a "must" on a turn controller.

Thanks for reading.

  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. It IS rare though for many turning jobs
to produce exactly what the drawing shows, due to tool geometry not matching the drawing even if compensated. LazyTurn will show, after each tools path is generated, what parts did NOT cut, its up tothe user then to select another tool that is capable of cutting the remaining stock, or accept the differences from original drawing. At least thats how I envision it working at this point.. Im leading up to a simulation/generation facility that shows what didnt cut very prominantly and allows you to recut just that portion with a new tool.

  To clarify what Im aiming for, as its different from LazyCams process, in LazyTurn, I want a user to import a profile, set a stock radius, as it does now. Then select from a group of buttons what to do. If you select facing, then you select a tool, tip direction will automatically be assumed by the fact your facing. The toolpath will be generated and youll be shown it cut that face. In bright red, will be areas that differ fromt he loaded profile to the cut result. You can then accept that or just select another facing operation, and a new tool, and cut from that last cut just removing material that the new tool can cut. ( though in facing I dunno why you would..).  You are then left with a profile, and stock showing the face now mathes the profile loaded. Youd then select roughing, select a tool, and hit generate, the tool will show you the cut, and the resultant profile will show in red what doesnt match your profile. You then could , for example, select finish, select a tool, and youll see the finsih tool remove all it can, again leaving behind a red profile of what doesnt match. Youll continue this type of sequencing until your stock looks like your profile. There may be differences you wish to recut with variosu tools, or you may decide thats good enough. The Gocde will then be generated from all the created paths as one Gcode file. This will include Facing, Boring, roughing and finishing passes in the order that best makes sense to you.

   In other words, on load you are shown a stock, and a profile. Its your job through selecting various operations and tools, to whittle the stock down to your profile. Each time you cut a stage, the stock will turn opaque, show the tool whittle it down, then the stock will turn semi transparent again, in bright red, so you can see where the stock is larger than the profile. The stock will never be smaller than the profile. . Its my hope that this is more intuitive than before, and will allow for more sequences to be done until your stock/profile match is as good as it gets with your tools.

Art