What's new
What's new

Most efficient way to program multiple parts in Speedio

GiroDyno

Cast Iron
Joined
Apr 19, 2021
Location
PNW
This is a topic that has come up a few times, but maybe this situation is a little unique because it is for a very specific process. We make our own product line, a family of various shapes/sizes of the same thing, 2 dedicated fixtures per table, 1 part per fixture, running on an R650 pallet changer.

Right now we post one full program, break it up into discrete operations based on tool, and then run those as subs. G54 T1 P1, G55 T1 P2, G55 T2 P2, etc...
The process makes it easy for operators to stop and adjust a tool offset and jump back to the right part at the right operation
The downside is it involves tedious hand editing copy/past to break it into subs (which is prone to minor errors), and that has to be redone if there's a rev change to the part. It also doesn't play well with some of the Brothers bonus features like G100

I want to refine the workflow for these parts and am wondering what other strategies are available and popular for this type of work. I basically see three options: Program/post one part and keep using subs, program one part and duplicate it in CAM before posting, or program two parts.
Programming two parts sounds tedious, but in my head seems like it would give me the most efficient program... I'd need to do some testing to see what posted code looks like and how I can make it switch between WCS mid operation...
Fusion has two ways of replicating your program, either duplicate/pattern operations or to "post to multiple WCS". I've used patterns in CAM for repeating parts before but not in any sort of production setting so I'm not sure what kind of drawbacks/inefficiencies will arise.
I loathe the hand editing/copy pasting process to make the subs, really don't want to continue down that path but if its the best bet than so be it!

We don't run different programs between the two pallets, sometimes the pallet will change and a "finished" part will need a heavier chamfer or something so we flip the table back and rerun using the saved probe data, so I'd like to retain 4 different WCS for each fixture, G54/55 on P1 and 56/57 on P2.
 
Option 4… program 1 part duplicate it with the post processor so that part 1 is g54 and part 2 is g55…. Copy that program for pallet 2 and edit g54 to g56…. g55 to g57 and run different programs on different pallets.

Option 5….Generally I agree you want a unique work offset for every fixture but you don’t necessarily have to do this. Can you combine both fixtures on a single fixture so that only one offset is needed? You’ll still probably want unique offsets (and programs) between the pallets.

Duplicate functions before the post processor can be great but they can cause trouble. Mirror functions can take a path from climb to conventional. Or a mirrored path with a reverse can go from top down cutting to bottom up. If you’re mirroring stuff, just program 2 parts or have the post process make 2 parts. Translate functions should be more straightforward.

Anyway you go you probably want the ability to run different programs on different pallets.
 
Hi, I've been doing some significant work on the Brother post and trying to bring in all the changes from various community edits, plus fixup some of the other issues with the autodesk version (eg fixing the Blum probing). You can find that here:

https://github.com/ewildgoose/fusion-360-post-processors

However, someone asked me about adding the ability to post out a program into multiple files. Fusion does appear to have this capability! However, at the time I couldn't completely see the value or use case to real users so haven't chased that further. However, if there was demand, it's definitely something I could look into, however, I'm not totally sure what granularity we have, it might be one file per operation?

Without making other changes, I would suggest you try the "multiple WCS" option in Fusion. Also note that when setting up the NC program, you have a tick box to re-order operations by tool. I suspect that between these two options (and perhaps splitting out into 2 NC programs? Thinking you might prefer to push the probing and setup at the start to a separate program?), then you can get the amount of manual edits down to near zero?

What the "multiple WCS" does is post the program multiple times, each time with an incremented G5x option. So this means you need to use consecutive WCS numbers (likely not a problem). This can then optionally be re-ordered to do the part one at a time, or use a single tool across both parts before changing (likely what you want?)

The pattern option can be useful if you have a fixture place and stuff was made by the same machine. So you setup one program and then run it multiple times at an offset. However, this means you can only use a single WCS, so you would need to do some probing, then setup 2 patterns and have them carefully constructed to be the difference between the WCS's on a single pallet. I seem to recall this can also do tool re-ordering,

The simulation was buggy with the multiple WCS and probing when I last tried it (didn't factor in the extra WCS and only simulated a single probe op), however, it posted out correct code (do check of course).

Hit me up privately if you or anyone else has any feature requests for this post though?

(Just working on a "verify" op at the moment. Something like an op stop on steroids. Retracts the spindle and moves the pallet to the door so you can take a look at it)
 
Can you DM me a sample program complete from Fusion, along with the broken up subprograms? I'd like to see exactly what you're doing and then take a stab at writing a simple web app that'll do it all for you automatically.
 
Since I am doing some programming I tested using multiple offsets in Fusion. The only thing I don't like about the code is it sends the Z home before moving to the next offset. Remove that line and it looks good to go.
 
What's that cost you on a Brother? 0.3secs..? 😁
Probably closer to a second. When programming for production you trim all the fat off, and that's pure fat. I figure that is a pretty easy post change. Or drop the G28 and make the Z move distance a configurable post property.

Speaking of which, is that the same section of the post for the Z axis retract when rotating the 4th???
 
Last edited:
If you can show me a bit of an example, I'll take a look at the retract?

The retracts happen in function writeRetract(), you can pass the axis you want retracted. You will see various logic here to move the X/Y axis to home positions, etc

The call to writeRetract is probably from onEnd, which is the last step of the process. My guess is that you posted it WITHOUT the re-order tools, and so Fusion is just doing dimbo run through all operations twice, once for each WCS. So you end up calling onEnd twice (hence the mid retract)? That's a guess though, I would need to take a closer look.

Assuming we can detect there are more operations to come then we could skip the (full) retract.

Yes, this will be what causes the retraction when rotating the 4th. However, before you go in too hard rewriting the writeRetract call, I think look for where the call comes from and tweak there? If you can show me a simple test file then I can take a look. I think the implied question you are asking is something like: Can we add a "retract height when spinning the 4th" option to the post config?
 
Since I am doing some programming I tested using multiple offsets in Fusion. The only thing I don't like about the code is it sends the Z home before moving to the next offset. Remove that line and it looks good to go.
Fusion tends to be very conservative, I suspect this is another of those areas.

If you know how to make this an editable thing in the post I'd love it if you shared.
 
Fusion tends to be very conservative, I suspect this is another of those areas.

If you know how to make this an editable thing in the post I'd love it if you shared.
Yeah, Fusion has some pretty serious training wheels like this. Freds modified my Yasnac post in 2018 so I can set the retract distance in the Post Properties when posting but AD changed the post structure enough that I can't figure out how to do it to my Brother post. I have been bugging hi-fly-cnc about this some as well as other changes and we will let everyone here know when/if it gets done. If you haven't already you should try his post out, it is on GitHub. I like it other than all of the clutter that he likes.
 
You could set that retract to post as a macro variable that you can assign a value to in the header of the post. That way you can set it to one number in your templates using a 4th and a different value in templates for vise work, or dedicated fixtures etc...
 
You could set that retract to post as a macro variable that you can assign a value to in the header of the post. That way you can set it to one number in your templates using a 4th and a different value in templates for vise work, or dedicated fixtures etc...

How do you imagine this working?

Something like in the header an "IF #199 NE #0" would set #199 = default retract distance
Then the retract would go to Z[#199]

So on the control you can go in and edit #199, but if it's not set then we apply a default? Default being customisable in the NC program main page? (Or we could use a #500+ if you want it to persist past machine shutdown?)
 
Yeah, Fusion has some pretty serious training wheels like this. Freds modified my Yasnac post in 2018 so I can set the retract distance in the Post Properties when posting but AD changed the post structure enough that I can't figure out how to do it to my Brother post. I have been bugging hi-fly-cnc about this some as well as other changes and we will let everyone here know when/if it gets done. If you haven't already you should try his post out, it is on GitHub. I like it other than all of the clutter that he likes.

I think you might be able to partly do what you want in the existing setup

I haven't double checked this, but I think the retract at the end is driven from the "machine definition" "Home" location. So whilst it's not very customisable, you could create a machine definition for use with the 4th for "general production", where the Z retract is set low. Another machine definition for "development" where the home Z is set way up in the air near the moon.

Swapping between them is just one dropdown in the NC Program definition. So not too bad.

I do agree it wouldn't suit a use case where you wanted to tune the retract on a per job basis, (but I would also point out that with 50m/min rapids + 2.2G accelerations, there isn't too much time lost with a bit of excess movement)
 
How do you imagine this working?

Something like in the header an "IF #199 NE #0" would set #199 = default retract distance
Then the retract would go to Z[#199]

So on the control you can go in and edit #199, but if it's not set then we apply a default? Default being customisable in the NC program main page? (Or we could use a #500+ if you want it to persist past machine shutdown?)
Something like the post or a manual NC outputs #500= X.XXX in the header, then have those retracts post a hardcoded Z#500 instead of Z home
If you use templates for programming you could save #500= 'way up there' in your 4th axis template and #500= 'not so high' on your vise (or pallet, or vacuum fixture, etc...) template. Otherwise it could be something defined in post properties.

@DavidScott What does a tool change look like with the multiple WCS option enabled? Does it still output G100, and does it order operations to minimize machine travels (ex. Op1xWCS 1, Op1xWCS 2, Op2xWCS 2, Op2xWCS 1, Op3xWCS 1, etc...) or does it always do the "first" WCS first for each op?

I just had to run some parts on our Haas using some nested patterned operations and I definitely don't like how that code looked but I have yet to start experimenting with the options on the Brother.
 
The toolchanges are the same, the only difference is when the tool has done all it's work instead of changing to the next it starts all over with the next fixture offset, so no wasted movement other than Z home. It only goes G54, 55, etc, so there is some fat there.

I am out of my shop now but when I get back I will post about how Freds modified my Yasnac post to properly retract for 4th moves including the post code. I have 2 identical Yasnac posts, one for 3 axis and one for 4 axis so it is easy to spot the changes.
 
How do you imagine this working?

Something like in the header an "IF #199 NE #0" would set #199 = default retract distance
Then the retract would go to Z[#199]

So on the control you can go in and edit #199, but if it's not set then we apply a default? Default being customisable in the NC program main page? (Or we could use a #500+ if you want it to persist past machine shutdown?)

Sorry to keep the tangent going, but this is what I do for the tool retract. Keep in mind I'm not on a Speedio, and I don't use Fusion, but I do a lot of 4th axis and typical vise work. I had my guy edit my post to make my "clearance plane" from my CAM output as G59. G59 is always my rotational clearance as well as plane clearance with 3-axis work. This example is from a program on a HAAS VF2SSYT:

#5323=#14003+0.5 (SET G59 Z0. CLEARANCE PLANE ABOVE PART USING G154P1)

This line is hand coded into the beginning of every program. I machine strictly in the extended offsets, and the tallest part in this operation happens to be in G154P1. I have an Excel sheet that is pretty loaded. It has my different controllers/machines, drop down menus for all of the offsets, and then allows me to do calculations. It then generates the line of code I need to set the clearance plane so all I have to do is copy/paste out of Excel into the beginning of my program.

On the machine post side, it simply outputs a G59 whenever I change work offsets. I never have to edit it, I never have to think about it. I simply add a G59 equation at the beginning of my program and I know that my tool will stay 0.5" (or whatever you want it to be) above the tallest part. I don't know if Fusion has the capability, but it really has been a huge help when I'm doing a lot of multi-stage or multi-part operations within a single program.
 








 
Back
Top