Lathe Macros

Is there a way I can see the code to try and debug what is happening? It is obviously running the sub routine as the spindle starts up but then gets stuck on some variable maybe.

mariusl wrote: Is there a way I can see the code to try and debug what is happening?.

You could try putting (debug, ...) comments in the G-code routines to see where it is getting to.

What happens if you call the subs from the MDI window ( O<turning> call ) ?

I know what the problem might be. The subs run in CSS and feed-per-rev mode. Do you have a spindle encoder?

F**k, Gscreen will not allow me to use the "i" key in the MDI input.

But if I load the chamfer file it runs ok from MDI.

andypugh wrote: I know what the problem might be. The subs run in CSS and feed-per-rev mode. Do you have a spindle encoder?

Not yet it is on the to-do list. So it never get spindle up to speed condition right?

mariusl wrote: Not yet it is on the to-do list. So it never get spindle up to speed condition right?

Aye, so try changing the G-code preambles to feed-per-min and fixed-rpm mode.

I might do that for the short term but I already designed and ordered the slot disc for my encoder this morning. Might as well just do it right from the start otherwise it never gets done

Ok that works very well now. I cut the first part.
If I may suggest, what would be handy is if you put a mode select radio button on that will allow the user to chose between CSS or Feed rate mode. If Feed Rate mode is selected, the input box for CSS could be come the feed rate or there could be a separate input box for feed rate The subs will have to change as well I suppose.

The boring routine has a bad behaviour. If you cut an ID with a taper, the retract position is calculated from the start of the taper and causes the tool to plunge into the taper and remove it on the way out. The retract should be calculated from the end diameter of the taper.

I don mind fixing these little problems but it means that I will rewrite the routines with variable names in order for me to understand. I am not as clever as you with the numbers.

mariusl wrote: The boring routine has a bad behaviour. If you cut an ID with a taper, the retract position is calculated from the start of the taper and causes the tool to plunge into the taper and remove it on the way out. The retract should be calculated from the end diameter of the taper.

Oops!
I assume I must have fixed that in my own version, as I have cut many tapers