anafranil online
IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Accurate machine time, Accurate machine time
Bob Gray
post Aug 7 2015, 07:21 PM
Post #1


Advanced Member
***

Group: Members
Posts: 33
Joined: 22-January 14
Member No.: 3,592



On a recent job with a lot of rotary machining Sprutcam gave a time of 41 minutes. But actual machine time is 1:36:56. There a way to fix the machine definition so the calculated time is closer to the actual machining time?

Thanks
Go to the top of the page
 
+Quote Post
Mike Henry
post Aug 7 2015, 08:22 PM
Post #2


Advanced Member
***

Group: Members
Posts: 235
Joined: 12-December 07
Member No.: 50



QUOTE (Bob Gray @ Aug 7 2015, 07:21 PM) *
On a recent job with a lot of rotary machining Sprutcam gave a time of 41 minutes. But actual machine time is 1:36:56. There a way to fix the machine definition so the calculated time is closer to the actual machining time? Thanks





Bob,

I use SprutCAM 9 and Imperial units with a Tormach mill and find that the estimated cycle time for 2-1/2D or 3D tool paths is pretty accurate so long as I make sure to set the rapid feed rate for the correct value in SprutCAM. In my old early PCNC 1100 mill that is 60 ipm, whereas Tormach defaults to 500 ipm. It sure would be nice if fixed values like this could be adjusted in the SprutCAM machine definition to make them default to the correct value each time another project is started.

I haven't done any 4th axis work yet, so can't comment on the cycle time accuracy there.

Mike

Go to the top of the page
 
+Quote Post
Sprut_UK
post Aug 8 2015, 01:19 PM
Post #3


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



QUOTE (Bob Gray @ Aug 7 2015, 08:21 PM) *
On a recent job with a lot of rotary machining Sprutcam gave a time of 41 minutes. But actual machine time is 1:36:56. There a way to fix the machine definition so the calculated time is closer to the actual machining time?

Thanks


The machine definition has nothing to do with machining time calculations.
My guess at the moment would be that when using the rotary axis the machine control is using 'inverse time' feedrates (G93?)? These feedrates are calculated by the postprocessor rather than SprutCAM itself. Maybe this is where your investigations of this should be focussed?


--------------------
"Never interrupt your opponent when he is making a mistake..." - Napoleon Bonaparte
www.sprut.co.uk
Go to the top of the page
 
+Quote Post
Sprut_UK
post Aug 8 2015, 01:21 PM
Post #4


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



QUOTE (Mike Henry @ Aug 7 2015, 09:22 PM) *
Bob,

I use SprutCAM 9 and Imperial units with a Tormach mill and find that the estimated cycle time for 2-1/2D or 3D tool paths is pretty accurate so long as I make sure to set the rapid feed rate for the correct value in SprutCAM. In my old early PCNC 1100 mill that is 60 ipm, whereas Tormach defaults to 500 ipm. It sure would be nice if fixed values like this could be adjusted in the SprutCAM machine definition to make them default to the correct value each time another project is started.

I haven't done any 4th axis work yet, so can't comment on the cycle time accuracy there.

Mike


Hi Mike,

I think that the default feedrate values can be set via a machine configuration file (*.xml), although I don't have any specific information on how to do this.
Another method would be to create user operations that have the required rapid feedrate already set.

Dave


--------------------
"Never interrupt your opponent when he is making a mistake..." - Napoleon Bonaparte
www.sprut.co.uk
Go to the top of the page
 
+Quote Post
Mike Henry
post Aug 9 2015, 09:13 PM
Post #5


Advanced Member
***

Group: Members
Posts: 235
Joined: 12-December 07
Member No.: 50



QUOTE (Sprut_UK @ Aug 8 2015, 01:19 PM) *
The machine definition has nothing to do with machining time calculations. My guess at the moment would be that when using the rotary axis the machine control is using 'inverse time' feedrates (G93?)? These feedrates are calculated by the postprocessor rather than SprutCAM itself. Maybe this is where your investigations of this should be focussed?


Dave - Is there a way to change the default rapid feed rates in SprutCAM 8 or 9 either by machine or for the product in general?

Thanks, Mike

Go to the top of the page
 
+Quote Post
Sprut_UK
post Aug 10 2015, 09:52 AM
Post #6


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



I have checked with the software engineers and they say that the only way to create your own default feedrate values (including rapids) is by the creation of custom operations. You can also save the feedrate with a tool in the tool library (not rapids).
Attached File(s)
Attached File  Custom_operation.png ( 36.13K ) Number of downloads: 6
 


--------------------
"Never interrupt your opponent when he is making a mistake..." - Napoleon Bonaparte
www.sprut.co.uk
Go to the top of the page
 
+Quote Post
Mike Henry
post Aug 10 2015, 03:16 PM
Post #7


Advanced Member
***

Group: Members
Posts: 235
Joined: 12-December 07
Member No.: 50



QUOTE (Sprut_UK @ Aug 10 2015, 09:52 AM) *
I have checked with the software engineers and they say that the only way to create your own default feedrate values (including rapids) is by the creation of custom operations. You can also save the feedrate with a tool in the tool library (not rapids).


Thanks Dave. I'll drop a note to support and ask if they can include that rapid feed rate as a global value in future.
Go to the top of the page
 
+Quote Post
Bob Gray
post Aug 10 2015, 07:03 PM
Post #8


Advanced Member
***

Group: Members
Posts: 33
Joined: 22-January 14
Member No.: 3,592



Ive studies the program and rapid moves are not the problem. I'm using rotary machining and the error in the run time seems more to do with how moves with feed are calculated. Once the tool touches the part there are very few rapid moves.
Go to the top of the page
 
+Quote Post
Mike Henry
post Aug 10 2015, 09:40 PM
Post #9


Advanced Member
***

Group: Members
Posts: 235
Joined: 12-December 07
Member No.: 50



QUOTE (Bob Gray @ Aug 10 2015, 07:03 PM) *
Ive studies the program and rapid moves are not the problem. I'm using rotary machining and the error in the run time seems more to do with how moves with feed are calculated. Once the tool touches the part there are very few rapid moves.





Bob - sorry then, I'm out of ideas unless Sprut is assuming some an erroneous feed rate that is causing the run time calculator to grossly underestimate the cycle time.

Go to the top of the page
 
+Quote Post
Sprut_UK
post Aug 12 2015, 07:21 PM
Post #10


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



The point that I am trying to make about the inverse time issue is that if you are machining a small diameter part, the actual 4th axis on the machine itself might not be able to traverse at the calculated (inverse time) feedrate, so it will actually machine the part at its fastest feedrate.............which could be quite a bit slower than that calculated by SprutCAM (or any CAM).
It is similar issue when turning a part on a lathe that is equipped with CSS, the smaller the diameter being turned, the faster the spindle must run, if the spindle speed max's out, the effective feedrate is subsequently reduced.

Theoretically, you could test this on your mill by reducing the programmed (linear) feedrate in the SprutCAM project (50%?) and then trying this new program on the machine to see if the time error is reduced or eliminated.

If you decide to try this, could you please let me know about your results?

Dave


--------------------
"Never interrupt your opponent when he is making a mistake..." - Napoleon Bonaparte
www.sprut.co.uk
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



Lo-Fi Version Time is now: 17th July 2019 - 10:24 PM