Is there a way of seeing how long the work will take to machine?
When using MillCAM designer in the past, once the G-Codes were generated, it would tell you how long it would take to machine.
Does the order in which the items are selected in the machining plan affect the timing of manufacture?
MillCAM designer Machining Times
Moderators: Martin, Steve, Mr Magoo
-
Denford Admin
- Site Admin
- Posts: 3649
- Joined: Fri 10 Feb , 2006 12:40 pm
- Hardware/Software: Go to User Control Panel > Profile
Enter as much information about your CNC hardware and software as you can - it makes it easier for everyone to know what you're talking about then. - Location: Sunny Brighouse
- Contact:
We have tried to do timings in the past before, and it has never worked out.
This is due to the machine having turbo and move blending.
eg:
You could run a program without turbo on, and it would take 35 minutes
Run the same program with turbo, and it may take 5 minutes !
Even taking the default case of using turbo, it is still very difficult to pre-calculate exactly what accelerations and decelerations will occur between some of the moves - this would also vary a great deal between machine types, connection method (USB or RS232) and speed of PC.
eg:
A slow PC will take longer to process each move, and send down to the machine. Even if the difference is fractions of a seconds, over thousands of moves, the time estimation would be way off the mark.
All in all, we would probably have more complaints that the time estimate was constantly wrong, than we would have people asking for it to be implemented.
You will soon get a feel for how long jobs will take
This is due to the machine having turbo and move blending.
eg:
You could run a program without turbo on, and it would take 35 minutes
Run the same program with turbo, and it may take 5 minutes !
Even taking the default case of using turbo, it is still very difficult to pre-calculate exactly what accelerations and decelerations will occur between some of the moves - this would also vary a great deal between machine types, connection method (USB or RS232) and speed of PC.
eg:
A slow PC will take longer to process each move, and send down to the machine. Even if the difference is fractions of a seconds, over thousands of moves, the time estimation would be way off the mark.
All in all, we would probably have more complaints that the time estimate was constantly wrong, than we would have people asking for it to be implemented.
You will soon get a feel for how long jobs will take
The time taken can be calculated looking at the distance the tool travels in the program and the feedrate it moves per minute.
The problem is the tool is not travelling at a constant velocity and any axis reversal causes the slide to have to decelerate to a stop then accelerate to speed again.
Where the program has lots of short moves the cycle time will generally be longer as the axis never gets up to full speed as it is constantly running in the accel and decel feedrates.
A distance travelled in program could be calculated but simply deviding this by the feedrate will not give an acurate time.
The problem is the tool is not travelling at a constant velocity and any axis reversal causes the slide to have to decelerate to a stop then accelerate to speed again.
Where the program has lots of short moves the cycle time will generally be longer as the axis never gets up to full speed as it is constantly running in the accel and decel feedrates.
A distance travelled in program could be calculated but simply deviding this by the feedrate will not give an acurate time.