Multiple Parts using Work Offsets, Subroutines and Sequential Serial Numbers

Hi Folks. There have been different threads on Subroutines over the years. I recently read though some of them and then set up a multiparts job, and made a video of the process.

I think many of you get your CAD/CAM software to do this, but I wanted to find a way to upgrade proven code edited on machine.

Please post your method of coding for multiparts and related subjects. Cheers Cliff

https://www.youtube.com/watch?v=kbxPuX5jo-c&t=1271s

Hello.

Take a look at the following web page. You may find what you´re looking for.

11.14. Subroutine and subprograms call (all machines)

Regards.

Good video again Cliff.Pathpilot now supports M98 Pxx Lxx where M98 calls the sub,P is the number of the sub and L is the number of repeats.In your example using o01 you would still name it the same but would end it with M99 instead of o01 endsub and to use it you would have M98 P01 and L however many repeats you wanted or no L for a single pass.It seemed that to use o call the sub had to be in the program before the call but with M98 it can be at the end of the program below M30.When using a number of small subs I found it easier to keep track of them when they were all together at the bottom of the program.

Good video cliff.
I always learn something or pick up new idea for developing a strategy to get results in the shop from your videos.

Quote:

---

Originally Posted by ally-g

Good video again Cliff.Pathpilot now supports M98 Pxx Lxx where M98 calls the sub,P is the number of the sub and L is the number of repeats.In your example using o01 you would still name it the same but would end it with M99 instead of o01 endsub and to use it you would have M98 P01 and L however many repeats you wanted or no L for a single pass.It seemed that to use o call the sub had to be in the program before the call but with M98 it can be at the end of the program below M30.When using a number of small subs I found it easier to keep track of them when they were all together at the bottom of the program.

---

Thanks - That's good information. Cliff

Quote:

---

Originally Posted by mountaindew

Good video cliff.
I always learn something or pick up new idea for developing a strategy to get results in the shop from your videos.

---

Thanks! Good to hear my rambling is useful to some. Cliff

Quote:

---

Originally Posted by BBMNet

Hello.

Take a look at the following web page. You may find what you´re looking for.

11.14. Subroutine and subprograms call (all machines)

Regards.

---

Thanks for posting that. More good theory on the subject. Cheers Cliff

Hi Cliff
There's nothing missing with your approach. You just list the offsets and call the subroutine individually instead of in a loop. The only change I would have made would be to add (in this case repeat) the initial work offset just above the first sub call. This would be just for readability, it won't affect execution.

Just as you were commenting that the G54.1 Pxx offsets are not visible in the status list you were looking right at where they were displayed :)

Attachment 445970

As you've already machined the fixture you know the relative positions, so like you mentioned in the video I would probably have offset the code instead of using separate work offsets.

One last point, I try never to manually modify any code generated by a tool. If I need to "tweak" generated code I always return to the tool if at all possible. I very often need to add or change an op, perhaps just add a chamfer, and I'm guaranteed to overwrite any manually entered changes or forget to add something again.

Regards
Step

Quote:

---

Originally Posted by TurboStep

Hi Cliff
There's nothing missing with your approach. You just list the offsets and call the subroutine individually instead of in a loop. The only change I would have made would be to add (in this case repeat) the initial work offset just above the first sub call. This would be just for readability, it won't affect execution.

Just as you were commenting that the G54.1 Pxx offsets are not visible in the status list you were looking right at where they were displayed :)

Attachment 445970

As you've already machined the fixture you know the relative positions, so like you mentioned in the video I would probably have offset the code instead of using separate work offsets.

One last point, I try never to manually modify any code generated by a tool. If I need to "tweak" generated code I always return to the tool if at all possible. I very often need to add or change an op, perhaps just add a chamfer, and I'm guaranteed to overwrite any manually entered changes or forget to add something again.

Regards
Step

---

Thanks for your thoughts Step.

Re: As you've already machined the fixture you know the relative positions, so like you mentioned in the video I would probably have offset the code instead of using separate work offsets.

How would that look Step?

Re: I try never to manually modify any code generated by a tool. If I need to "tweak" generated code I always return to the tool if at all possible. I very often need to add or change an op, perhaps just add a chamfer, and I'm guaranteed to overwrite any manually entered changes or forget to add something again.

Yes I can see that is best practice. I but if your CAM software or CAM software skills are limited, or if you are combining two limited CAM codes (eg Bobcadcam and Pathpilot conversational serial numbers, I imagine some practical non software types like me can better do this via on the machine editing.

But please challenge me on this if you disagree. I can see your approach is best practice and would ensure that software skills are improved over time, so it is a key point.

Cliff

Quote:

---

Originally Posted by keen

How would that look Step?

---

I hoped you wouldn't ask :)
I would normally try to just create an array of models in CAM and let the CAM do the hard work. However, adding custom g-code like G47 doesn't play well with this approach.

So:

The first attached program (increment_wcs.nc) calculates and sets an array of work offsets based, in this example, on the current G54. it assumes G54 has been set to the X0, Y0 location the first op and the code calculates and sets the remaining work offsets sequentially using the specified x and y increments. The example sets work offsets beginning at G54.1 P10, which will be equal to G54, and calculates a 4x2 array with x spacing = 40mm and y spacing = -20mm. The last work offset in the series would be G54.1 P17.
Run this program first to set up the work offsets and then use your existing program using 8 work offsets (beginning with G54.1 P10) while only the first needs to be located. Just modify the x and y increment sizes to taste.

The second program (incrementing_serial.nc) uses G92 offsets to generate an array of serial numbers. Yes I know Tormach states: "This is a legacy feature. Most modern programming methods don’t use temporary work offsets.", but I'm also what you might call "legacy", so I find this method fits nicely.
It creates a 4x2 array of serial numbers by simply adding the specified offsets to the current work coordinate system and calling the subroutine <DoSomething>.

Both methods work fine for just one repeated op but become less convenient for multiple ops on each part, unless all use the same tool. That's why I would prefer to generate as much as possible in CAM. Perhaps someone else has a better approach?

Step

Hi Step. Thanks for going to the trouble of that comprehensive response.

How long did that take you? Cliff

Quote:

---

Originally Posted by keen

How long did that take you?

---

TOO LONG! I've programmed quite a few similar routines in the past but the last was over a year ago. The syntax is a little strange and it took a while to get used to it again. It's always useful to have some additional examples so the next time won't take (quite) so long...
Step

I'm like t-step mentions and I try to do as much in cam as possible.
I would setup a cam program with 1 g54 offset and array the parts off that as required at fixed distances and mill them all. This would limit tool changes.
Then Use t-steps increment-wcs to load those same numbers into the required g59x offsets in PP.
Then it would be a toss up. either keen or steps code could be stitched up pretty fast to get all the right serial numbers to land on the offsets in one operation.
Good reading :)

I can draw one part, export to sprutcam, use the transform function to machine the multiple parts, quick and easy, I would like to add sequential serial numbers to some of the parts at some point though.

Quote:

---

Originally Posted by popspipes

I can draw one part, export to sprutcam, use the transform function to machine the multiple parts, quick and easy, I would like to add sequential serial numbers to some of the parts at some point though.

---

Hi Mike
As I mentioned earlier that's the way I would normally create multiple parts but G47 doesn't fit in too well with this approach (please let me know if I'm missing a glaringly obvious solution!). The code for the serial number generation is just one single statement but contains the X and Y coordinates:

Code:

---

G47 X0 Y0 Z-0.25 P[8/3] Q4.00 R2 D3

---

This line could be added with Sprutcam using a macro or Fusion using a "Pass through" but the coordinates would need to be incremented for each part, otherwise the serial numbers would all be machined on top of each other. In this case it wouldn't actually be too difficult to call G47 8 times with different coordinates, especially if the numbers were convenient (like G47 X0 Y0... G47 X2 Y0... G47 X4 Y0... etc - but even when writing this example I made a stupid mistake!). On the other hand, in the real world subroutines usually contain multiple commands, and like in Cliff's example the coordinates are not nice round numbers.
Cliff solved this problem by creating a separate WCS for each part so the relative positions of the serial numbers with respect to X0 Y0 of each WCS always remained the same. My second variant used just one WCS but offset this WCS for each part, with the same result.
There's no "one size fits all" solution but it's useful to have a range of available options when you come across the inevitable next problem.
Step

Edit: another possibility:
If the X and Y parameters are not specified the current position is used for the serial number origin. If the CAM can position the tool at the correct coordinates for each part the G47 would automatically engrave the number at the corresponding location. I can't think of a direct way of moving the tool to specific position in CAM without actually performing an op except by adding a line of G-code (perhaps it will occur to me as soon as I post this) but perhaps a pseudo drill op at the serial number origin using the engraving tool but drilling in air just above the part? Any better ideas?