Hi. Having a quick kickaround at maiking a snail, and I've run into some problems.

This is the code i was using five minutes ago, it worked then but not now.

#1=45
G0 X0 Y[#1]
G0 Z1.00
M3 M8
G01 Z-1.0 F200

M98 P1 L10

G0 Z10 M5 M9
M30
O1

G03 X0 Y[#1] I0 J0 F600
#1=[#1+7.0]

M99
%

this isn't for making anything, just a tester for cutting a jig for trimming a ring shaped part on, hence the locating island in the middle.

The increasing Y value in the subroutine should force the tool round in an outwardly increasing helix, and annoyingly, five minutes ago it did ... but not any more .. And i can't think why. Any clues?

G02 or G03 commands repeated with a decreasing Z are quite ok, I use these all the time for milling dead-fit holes for dowels etc. Never a problem there. Just flat helixes, or helices or whatever they are when they're at home. Any clues?  

update on this - a lot of the hangups seem to have been caused by Gcode edit windows staying open and not being saved and closed. Poor housekeeping the other bug I've found is that if I displace the Y variable (#1) by more than 12 mm per revolution, it gives me an error of "Radius to end of arc differs to start". It just seems very odd to me that 12mm offset is tolerated, but 13mm is not.

Still puzzled. Any help appreciated on this, as i would like to drive a coarser spiral than I currently can.

Edit: the allowed displacement seems to be independent of the initial or eventual arc diameter. I increased the starting radius to 200mm and it still allows 12mm increase but not 13.


 

That is a QUIRK that ART left in the arc code ON PURPOSE.   It allows it up to about a .5" offset, BUT no more.

Hmm. If it's just a happy accident will it remain in mach4 when it finally arrives?

More to the point, is there a "proper" way of cutting a flat helix?

YOu might try doing it in segments, but that is also like doing an arc with line segments. It depends on the quality you are looking for.

Hi bp - You could take advantage of Art's "generosity" by instead of using the error once per circle - use it as many times as you like. Here's your code modified to use the error every quarter circle for example.

#1=45
G0 X0 Y[#1]
G0 Z1.00
M3 M8
G01 Z-1.0 F3000

M98 P1 L10

G0 Z10 M5 M9
M30
O1

G03 X[0-#1] Y0 I0 J0 F3000
#1=[#1+7.0]
G03 X0 Y[0-#1] I0 J0 F3000
#1=[#1+7.0]
G03 X[#1] Y0 I0 J0 F3000
#1=[#1+7.0]
G03 X0 Y[#1] I0 J0 F3000
#1=[#1+7.0]
M99
%

Hope this helps.

Cheers

Ian

Cheers Stirling - I was trying to do this yesterday but it was time for dinner and i had to go

Yes, this works for me, and very well, I will save it with my useful snippets of code. thanks.

My thoughts on this are that as bugs go, it's too useful to disregard. I may file a bug report on this and suggest that it be improved to allow an inch or more. thoughts on this? Obviously it could only be used in centre (I J) mode. Any idea what the proposal is for this "feature" in mach4 - remove it to improve compatibility with traditional controls like Fanuc, etc, or reinforce it as a feature, or just keep quiet?

To be honest I'd never realized until your post that Mach allowed this error. Thinking about it though, I suppose there has to be some margin for error else CAMs would have to be infinitely precise in order to do arcs, so I'm thinking it's more a neccessity than a bug. I'm guessing Art thought - what the heck - a half inch should do it!

Cheers

Ian

I saved an old post from Art from the Yahoo Group, where he calls this a "hidden feature". I use it all the time for circular pocketing. I don't see any reason why it would not remain in version 4, but you'd really have to ask Brian that.

I think That this is unique to mach(;-) Most others have a true Helix gcode.

HUM I just tried the code but Mach would error out on the the First G03 Arc call " Zero radius  arc " the older  versions never did that it ran fine.

Maybe it got FIXED???


(;-)