"Local CS transformation doesn't supported" in NC output

[CountryBoy19]

First of all I'm a new Sprutcam user. I briefly worked with CNC about 8 years ago and I'm now getting back into it a little. I'm currently tasked with getting a Tormach PCNC 1100 making chips and the CAM I have is Sprutcam. After a week of watching tutorial videos and learning lessons the hard way (trial and error) I finally created a program, sort of...

The part has machining ops on 3 sides. I read on here that some had problems with G54 "doing its own thing" in Tormach so the recommended fix was to use G55 for side 1, G56 for side 2, and G57 for side 3. I have 3 local CS's set up, 1 for each side. I was under the impression that I would be able to individually program each offset in Pathpilot but that isn't the case. When looking through the code, at the beginning of the block of code for each side I get 3 messages in parenthesis that say "Local CS transformation doesn't supported". A google search of that phrase tells me nothing but ultimately the problem is that I cannot individually offset each of my local CS positions.

Can I get some guidance (or pointers towards videos, articles, or help topics) that can better guide me through what I did wrong and how to individually set the program offsets for my local CS's?

[mountaindew]

I wouldnt worry much about using g54 offset causing problems. The format and use of m1 to stop progam and then setting start position in code to a very specific place causes the PP to jump to last operation in program and execute with whatever tool and offset is active. While this is very bad, chances of you setting and starting and running code this way is remote. The bug is still there to this day but I would not worry about it.

Setting up parts and running multi-side parts is somewhat advanced. If your just starting out your better off setting up parts one side at a time, I could send you a sprutfile as an example or one of the many templates I have preset and ready to run multi-sided parts but they would not help you that much at this point until you have more hours of time using this program.

Imho take your time and learn as much as you can using basic single side part setups then move to multi-sided parts in cam.

[CountryBoy19]

I wouldnt worry much about using g54 offset causing problems. The format and use of m1 to stop progam and then setting start position in code to a very specific place causes the PP to jump to last operation in program and execute with whatever tool and offset is active. While this is very bad, chances of you setting and starting and running code this way is remote. The bug is still there to this day but I would not worry about it.

Setting up parts and running multi-side parts is somewhat advanced. If your just starting out your better off setting up parts one side at a time, I could send you a sprutfile as an example or one of the many templates I have preset and ready to run multi-sided parts but they would not help you that much at this point until you have more hours of time using this program.

Imho take your time and learn as much as you can using basic single side part setups then move to multi-sided parts in cam.

Is there a more simple way to use sprutcam to generate operations from multiple sides of a part that are broken into separate programs? IE, more like a batch processing sort of thing: set up and run X parts through side one ops, then change program, change setup etc, run parts through side 2 ops...The problem seems to be with my assignments of multiple local CS's or with the local CS numbers (55, 56, & 57). If it's the numbering and I do batches with separate programs I can use G54 for all 3 sides and that may resolve the problem.

A little more about my background: I'm generally able to conquer anything I set my mind to. I'm a full-time engineer that is quite familiar with modelling etc, and I run a machine-shop from home. I'm currently in a temporary work assignment that necessitates being able to machine parts, including multi-sided ops. I'm the only option they have right now; the other guy (that couldn't even use sprutcam at all) got sent home. I do plan to do a 1-side part just to see what is happening.

Lastly: have you ever heard of the "local cs transformation..." issue? I'm wondering if maybe it has something to do with the way it's being post-processed because the simulation within Sprutcam runs fine; it seems to be having troubles with "translating" from sprutcam to code. That's just my inexperienced opinion though.

[popspipes]

I use sprutcam 7, and I make 2 sided parts.

I write two separate programs to do that, both with g54 offsets.
I run several parts in a bar, run the number of bars I need for side A, then switch programs and run side B in the same fashion.

I have never tried using different offsets in the same program.

If MD says its tough to do, I just take his word for it as he is very good with Sprutcam!

[CountryBoy19]

I use sprutcam 7, and I make 2 sided parts.

I write two separate programs to do that, both with g54 offsets.
I run several parts in a bar, run the number of bars I need for side A, then switch programs and run side B in the same fashion.

I have never tried using different offsets in the same program.

If MD says its tough to do, I just take his word for it as he is very good with Sprutcam!

Do you run it as entirely different sprutcam projects as well? Or is there a way to generate separate programs from the same sprutcam project?

A few pointers on your general process would be helpful.

Thanks for all the help thus far.

I don't really understand what is difficult about running multi-side parts in the same program. Is it setting up the multiple coordinate systems in sprutcam or in Pathpilot? I think I have the sprutcam thing figured out. It's the path-pilot that is tripping me up. When I go zero my g55-g57 in Pathpilot they are all grayed-out except g54. I first tried it before loading my program. I thought maybe pathpilot was so smart that it wouldn't let me set a g55 if my program didn't call for it so I loaded the program and it still won't let me set g55 (they are all grayed out still).

Edit: to further clarify, I assumed that I would be able to zero g54 on my vice, then knowing my work offsets from local CS on part to the g54 CS on the vice, I could program each offset (g55-g57) individually and use work-stops to set my part on each flip to get the part in the right location. Seems simple to me; where have I failed at understanding this?

[CountryBoy19]

Figure it out.... I was setting workpiece/part offsets incorrectly in pathpilot, everything else was GTG on the program. I'm not sure what the "Local CS transformation doesn't support" means, the program seems to run fine without it.

[mountaindew]

Figure it out.... I was setting workpiece/part offsets incorrectly in pathpilot, everything else was GTG on the program. I'm not sure what the "Local CS transformation doesn't support" means, the program seems to run fine without it.

Great to hear!
Sprut is a powerful program with dozens of ways to get things done. The more time you spend with it the more productive you will be. If I even stop using it for a few weeks I get rusty and slow at setting things up. Very powerful program and provides great results with about anything you throw at it. There are bugs and problems and the user must always be careful with what the post processor spits out also. Not everything that simulates correctly is translated to good gcode. The program is complex enough that its hard to tell sometimes if its user, program or post process problem. But to date I can always find a way to get it done.
Stick with it and you will be making most anything you want

[popspipes]

Do you run it as entirely different sprutcam projects as well? Or is there a way to generate separate programs from the same sprutcam project?

A few pointers on your general process would be helpful.

Thanks for all the help thus far.

I don't really understand what is difficult about running multi-side parts in the same program. Is it setting up the multiple coordinate systems in sprutcam or in Pathpilot? I think I have the sprutcam thing figured out. It's the path-pilot that is tripping me up. When I go zero my g55-g57 in Pathpilot they are all grayed-out except g54. I first tried it before loading my program. I thought maybe pathpilot was so smart that it wouldn't let me set a g55 if my program didn't call for it so I loaded the program and it still won't let me set g55 (they are all grayed out still).

Edit: to further clarify, I assumed that I would be able to zero g54 on my vice, then knowing my work offsets from local CS on part to the g54 CS on the vice, I could program each offset (g55-g57) individually and use work-stops to set my part on each flip to get the part in the right location. Seems simple to me; where have I failed at understanding this?

I export into sprut a model of one side of the part, and write a program for that, side A
I then flip the part over in CAD and export that into sprut as side B and write aprogram for that side.

I machine a hole in the original program, side A thru the stock to indicate from for the side B.

This is just the way I have always done it, I have never used anything other than G54.

I just use a separate program for the side B with the same G54 offset.

MD used different offsets in the same program originally, but he had a problem with it in later releases of Sprutcam or Pathpilot??
maybe he will chime in on this problem.

I

[CountryBoy19]

Great to hear!
Sprut is a powerful program with dozens of ways to get things done. The more time you spend with it the more productive you will be. If I even stop using it for a few weeks I get rusty and slow at setting things up. Very powerful program and provides great results with about anything you throw at it. There are bugs and problems and the user must always be careful with what the post processor spits out also. Not everything that simulates correctly is translated to good gcode. The program is complex enough that its hard to tell sometimes if its user, program or post process problem. But to date I can always find a way to get it done.
Stick with it and you will be making most anything you want

I think the good thing for me is that I'm a full-time prototype/design engineer that spends 30+ hrs a week doing CAD work and my machine-shop at home gives me the machining background so it's very easy for me jump into something like Sprutcam and comprehend things with a little guidance. Not so easy to comprehend the g-code part so I struggled a little bit getting the coordinates zeroed when it came time to sit in front of the actual machine.

That being said, I definitely did a dry run with my hand on the feed speed slider to make sure the machining operations were happening where they should be for each coordinate system and that there were no collisions; good thing I did that because I apparently slipped up when zeroing the tools out and they were going about an inch lower than expect in the z... not sure what happened there, I zeroed them yesterday, shut the machine down overnight then ran the program today without re-zeroing tools.

I also found out that G-wizard feeds & speeds calculator makes the assumption that your machine has unlimited power as I definitely stalled the spindle on a face-milling operation today and I thought I had set my feeds and speeds VERY conservative based on what G-wizard spit out. I'm going to go back and massage that part of the code and try again tomorrow...

ETA: Question regarding the high/low spindle range. I think the facemilling op would have been find if I were in the low spindle speed range, but I need the high range for some other ops. After the mill stalled I reset, changed to low-range, and tried to run it again with the feed rate set even lower (but still the same DOC/toolpath). I immediately got an error that the speed requested exceeded the maximum spindle speed of the machine (the spindle speed didn't go over the max in low range until a few ops later, it wouldn't even start the facemilling op). If I add a M0 stop for speed range changes will that take care of the error?

I export into sprut a model of one side of the part, and write a program for that, side A
I then flip the part over in CAD and export that into sprut as side B and write aprogram for that side.

I machine a hole in the original program, side A thru the stock to indicate from for the side B.

This is just the way I have always done it, I have never used anything other than G54.

I just use a separate program for the side B with the same G54 offset.

MD used different offsets in the same program originally, but he had a problem with it in later releases of Sprutcam or Pathpilot??
maybe he will chime in on this problem.

I

Makes sense; are you compensating for material removed from side A when you do the program for side B or you're just letting it machine air when it comes to that point? I guess there is no harm in machining air in prototype and low-production cases. The engineer in me often tends to over-focus on optimization and efficiency... haha

[popspipes]

I think the good thing for me is that I'm a full-time prototype/design engineer that spends 30+ hrs a week doing CAD work and my machine-shop at home gives me the machining background so it's very easy for me jump into something like Sprutcam and comprehend things with a little guidance. Not so easy to comprehend the g-code part so I struggled a little bit getting the coordinates zeroed when it came time to sit in front of the actual machine.

That being said, I definitely did a dry run with my hand on the feed speed slider to make sure the machining operations were happening where they should be for each coordinate system and that there were no collisions; good thing I did that because I apparently slipped up when zeroing the tools out and they were going about an inch lower than expect in the z... not sure what happened there, I zeroed them yesterday, shut the machine down overnight then ran the program today without re-zeroing tools.

I also found out that G-wizard feeds & speeds calculator makes the assumption that your machine has unlimited power as I definitely stalled the spindle on a face-milling operation today and I thought I had set my feeds and speeds VERY conservative based on what G-wizard spit out. I'm going to go back and massage that part of the code and try again tomorrow...

ETA: Question regarding the high/low spindle range. I think the facemilling op would have been find if I were in the low spindle speed range, but I need the high range for some other ops. After the mill stalled I reset, changed to low-range, and tried to run it again with the feed rate set even lower (but still the same DOC/toolpath). I immediately got an error that the speed requested exceeded the maximum spindle speed of the machine (the spindle speed didn't go over the max in low range until a few ops later, it wouldn't even start the facemilling op). If I add a M0 stop for speed range changes will that take care of the error?


Makes sense; are you compensating for material removed from side A when you do the program for side B or you're just letting it machine air when it comes to that point? I guess there is no harm in machining air in prototype and low-production cases. The engineer in me often tends to over-focus on optimization and efficiency... haha

When I flip the half machined parts over (4 or 5 to a workpiece) to machine side B I reset Z zero, indicate the reference hole with a dial indicator, I use a fixture so the X is in alignment. Then switch the program to the one for the B side and its good to go.

[Little_Chips]

In GW Setup tab, click on the adjust button of the Spindle HP line. Then use the torque curve I attached. It is for the PCNC1100. Also I set the rabbit to about 75 to 80 percent as 100 percent is too aggressive imo.Attachment 338316

[Phillyb24]

Are you doing hole machining operations? On the strategy page under where it says NC code format there is a box that says Use Holes Coordinate System. That will pop up that error I'm pretty sure if I recall correctly.

[bll230]

When I have a part with top and bottom machining I machine the top with Global CS and G54, and then create a CS1 and locate it on the bottom side. I set the CS1 as G54. For machining I have a stop in the program so that I can flip the part, and then it continues machining the bottom side with G54 active. There is no need to write separate programs for top and bottom.

I have always been able to locate the CS1 on my part to use the same work offset so I have always used G54 both top and bottom, but to use multiple work offsets just set CS1 to G55, CS2 to G56 etc. and then the machine will used those offsets when you restart the program after each flip. If you had multiple vices you would need to have multiple offsets.

The video that Eric did while he was still at Tormach about flipping was pretty good. The only difference is I do not set the LocalCS to CS1, I keep it at off. From reading and rereading the Sputcam manual I concluded that the LocalCS was for older postprocessors that did not have some capability that the current ones have.

What was causing PathPilot to gray out your G55 etc?

John

[mountaindew]

I found if you organize your use of UCS g54-g59x into groups of operations makes the process easy to maintain and edit. A generic template can be saved with all the groups and all you need to do is load part and locate g54 -g59 on each side of part design and your off and running.

Example of the groups shown in list at left.

Attachment 339316

[bll230]

MD, neat arrangement, but I have one question. With that particular part what is the benefit of the multiple work offsets? With a cube isn't the zero in the same place for every face since you put it back in the vice in the same location every time, just with a different face pointing up?

[mountaindew]

MD, neat arrangement, but I have one question. With that particular part what is the benefit of the multiple work offsets? With a cube isn't the zero in the same place for every face since you put it back in the vice in the same location every time, just with a different face pointing up?

You are exactly right! Could have done one side and flipped part for all six sides. This was more for practice of setting ucs positions and also for the fun of watching a complete simulation of the part on all sides in one program. Also not shown in the picture there is vise and mill fixtures located and transformed for each side. Something to this day the people at Tormach do not understand how I do.. I sent an example like this to Tormach because I was getting a error on the new version 10. Turned out to be the chip pan is colliding with y axis. They said it was my fixtures! I am like my fixtures simulate perfectly on all sides in any way or combination I want to use them. Jake at Tormach said I could not do this and I'm like yes I can and never mind, I found the error just turn off chip pan on machine simulation and error goes away.

To this day I cant have chip pan on and all my simulated cam chips fall on the floor
I have a number of different templates with all the fixtures transformed in different ways and combinations like vise, pallet plates, 5c collets and even 4th axis ready to load part models into. Then all I have to do is move part into position, locate ucs position as desired and start filling groups with operations. Makes multi-side , multi fixture parts easy and down right fun to do. And I am talking all the way down to little screws that hold parts and the end mills or chamfer bits come as close as a sheet of paper and not touch or collide!

Using the EXTRA effort in the simulation has almost eliminated tool damage. But i still bozo things up now and then. Cant see it all even in good setups!

Example of fixture tool path check

Attachment 339410

[mountaindew]

Quick visual example
Attachment 339412

Note where fixtures are loaded organized and transformed on left side of picture
Attachment 339414

Each side of part has the fixture transformed and positioned for that side of part and those operations and then refrenced under the fixture tab.
G55 side
Attachment 339416

repeat for each side as desired and your on your way to using sprut built in collision avoidance features on multi sided, multi ucs parts.
G57 side
Attachment 339418

G56 side
Attachment 339420

This can be organized and done in a very straight forward manner it just takes time and effort.
Yes its complex but these methods have saved a lot of errors in tools, materials and even design pitfalls.

[bll230]

Thanks for showing all that. I knew Sprutcam could use fixtures like that but the examples help make it clearer. Where did you get the solid model of the Tormach vice?

John

[mountaindew]

Thanks for showing all that. I knew Sprutcam could use fixtures like that but the examples help make it clearer. Where did you get the solid model of the Tormach vice?

John

Tormach has some solid models of fixtures to download. I also have drawn a dozen or so others like 5c collet holders and custom fixture pkates