Spiral Subroutine

To all of my friends around the globe, here in America this is fathers day week end. This is the time we honor our fathers, or at least pretend to. My weekend has been busy with family activities, and therefore I have not been doing much with CAD or CNC. Actually I’ve been doing nothing. LOL. I hope to upload two more code files early this week. The first will control the step down sequence, while the second will be a parent program similar to the first, but will generate circular pocket holes.

ostrozub1:
This next upload may well be what you’re looking for. I guess you’ve already figured out that arguments entered as a call to a subroutine end up being deposited in #1, #2, #3, etc. That’s where those variables suddenly come from. In the documentation, if you look up, “O”, codes it will explain all of this.

pl7i92:
In your 6/2/19 entry you refer to code in the examples directory. Could you be more specific?

Grotius:
In your 6/9/19 entry you reference a program in github. I did take a look, at this file. Yes I am aware of the use of polar notation, but in this particular application, since I am starting from the center and working out this likely won’t work. The LinuxCNC documentation says that will likely generate an error. I know this doesn’t sound reasonable, and I will explain more fully when I upload the next two files.

Andy:
Regarding your 6/12/19 comment, if Grotius is correct and you did write this you have a nice piece of code. This takes me back to the days of Lindsaybks.com; when, in the 19th century, when steam was king, and a BS degree in mechanical engineering commanded a better lifestyle than that of a medical doctor. It was in one of those republished books I noticed a cam shaft similar to yours. The big difference is that it was a stack of cams on a threaded shaft. The shaft had a flat machined on one side, and the cams had an interior geometry to compliment the shaft. The cams were either milled, or hot stamped depending on the volume requirements. The interesting part of this is that if you wanted to change the behavior of the machine, you just replaced one or more of the cams. I guess you could call it 19th century computer programming. LOL! Anyway, it’s good to touch base with you. I have read many of your comments on other topics, but never dove in to give you a reply.

Grotius:
Regarding you’re comment of 6/13/19. Although you likely have not had a copy of The Home Shop Machinist, they do have a website. The URL for that is, “thehomeshopmachinist.net”. Check it out. You may find something interesting there.

To all of my friends around the globe, here in America this is fathers day week end. This is the time we honor our fathers, or at least pretend to. My weekend has been busy with family activities, and therefore I have not been doing much with CAD or CNC. Actually I’ve been doing nothing. LOL. I hope to upload two more code files early this week. The first will control the step down sequence, while the second will be a parent program similar to the first, but will generate circular pocket holes.

ostrozub1:
This next upload may well be what you’re looking for. I guess you’ve already figured out that arguments entered as a call to a subroutine end up being deposited in #1, #2, #3, etc. That’s where those variables suddenly come from. In the documentation, if you look up, “O”, codes it will explain all of this.

pl7i92:
In your 6/2/19 entry you refer to code in the examples directory. Could you be more specific?

Grotius:
In your 6/9/19 entry you reference a program in github. I did take a look, at this file. Yes I am aware of the use of polar notation, but in this particular application, since I am starting from the center and working out this likely won’t work. The LinuxCNC documentation says that will likely generate an error. I know this doesn’t sound reasonable, and I will explain more fully when I upload the next two files.

Andy:
Regarding your 6/12/19 comment, if Grotius is correct and you did write this you have a nice piece of code. This takes me back to the days of Lindsaybks.com; when, in the 19th century, when steam was king, and a BS degree in mechanical engineering commanded a better lifestyle than that of a medical doctor. It was in one of those republished books I noticed a cam shaft similar to yours. The big difference is that it was a stack of cams on a threaded shaft. The shaft had a flat machined on one side, and the cams had an interior geometry to compliment the shaft. The cams were either milled, or hot stamped depending on the volume requirements. The interesting part of this is that if you wanted to change the behavior of the machine, you just replaced one or more of the cams. I guess you could call it 19th century computer programming. LOL! Anyway, it’s good to touch base with you. I have read many of your comments on other topics, but never dove in to give you a reply.

Grotius:
Regarding you’re comment of 6/13/19. Although you likely have not had a copy of The Home Shop Machinist, they do have a website. The URL for that is, “thehomeshopmachinist.net”. Check it out. You may find something interesting there.

Regarding my post of 6/17/19, due to an error on my part, this reply was uploaded twice. Rather than correct both texts, I am making a correction here for both of these replies. In the last paragraph the URL I supplied is in error. The correct URL is, “homeshopmachinist.net”. I am sorry for both errors.

Thanks


Larry

As promised the last two files are completed. The two attached files are CircPocketParent.ngc, and depth.ngc. The second file, depth.ngc, is the top most callable subroutine on the program stack. Obviously, this file needs to be stored in the directory allocated for callable subroutines on your system. That file is called by CircPocketParent.ngc. Like the previous parent file, this one can go anywhere on your system. It's simply a file which demonstrates the depth subroutine and in practice will certainly be replaced by your actual application which would call depth.ngc.

Regarding depth.ngc, its purpose is to make recursive calls to spiral.ngc until the desired pocket depth is achieved. In addition, after rolling out of a spiral.ngc call, it performs a circular cleanup pass as evidenced by line number seven. This is necessary because a spiral is not a circle. Notice also that the, “g3”, arc continues past the starting point by 10 degrees. This is intended to further clean up any transitional error between the end point of the spiral and the beginning of the circle. For those of you who are new to hand, “G”, code programming, the parameters included on line number seven may look a bit cryptic. Don't worry, the documentation that comes with linuxcnc will explain what I did. After the circle is completed, line ten makes a conditional ramp decent, governed by the enclosing, “if”, statement to the next level to be pocketed. As a matter of programming practice, and safety, I avoid plunge entries into the work like the bubonic plague! Unless your end mill is off center ground, you risk breaking the tool, and, or damaging the work piece.

As for CircPocketParent.ngc., the first item I want to stress is the extremely large value of step down on line number six. This was done to spread the layers far enough apart so, in back plot, you could easily see what is going on. Please! If you try run this file on actual machinable stock reduce this value to something realistic. Also you will likely want to reduce the feed rate as well. What adds to the simplicity of the code in the program stack, are the calls to g92 and g92.1 in the parent program. This negates the necessity to include code to facilitate offsets to the location where you want your pocket to start. I have seen examples of code like this become blindingly complex in the programmers effort to make a subroutine like this relocatable.

As I have done from the beginning, I designed this code in a callable stack. Should you wish to improve any part of this stack you only have to work on that individual subroutine file. An additional feature of this type of programming is any subroutine can be called at any level of the stack. Consider your application is to machine a fresh casting. On this casting there a number of cast bosses who's faces you want to clean up. It's not necessary to call depth.ngc at all when a simple call to spiral.ngc will do the job.

Lastly, Grotius, I want to thank you for your code suggestion published on github.com. Back in 2016, in the early conceptual stages of this project I considered a piecewise linear approximation using polar notation in an incremental g91 loop such as that. However in the last part of the documentation in section 5.2.11 just before section 5.2.12 was the following warning, “It is an error if an incremental move is started at the origin”. Since I had already decided to start the spiral at the origin I decided not to pursue that path. If I had started at the perimeter and worked my way to the center, I would have had to make a g0 move to the perimeter for the clean up pass. Finally, on line one, of that file there is a g20 code meaning all dimensions are in inches. Assuming the material surface is at z0, that would mean a 100 mill plunge cut to begin the spiral. In my opinion, that could well spell disaster for a center ground end mill.

So this is it. The code has now been released into the wild. Do what you will with it. There is always room for improvement. If you find a better way to accomplish this by all means leave a reply with the code. This is how our little community grows.