[gyronikeleg]

Hello!

I am trying to calculate the exact times that my PCNC 770 is cutting and the exact times when it is not.
I have some code that runs through the g-code which calculates the time based on my feedrate value.

The problem I am having is that the mill does not run at exactly the feedrate I input when it is executing a path. As in, when I enter a feedrate of 20 in/min in sprutcam it moves at 19.5 in/min in some cutting portions and at 21 in/min in others.

This screws up my calculations. I don't know if I am overlooking a command in my g-code that allows the tormach to compensate for some reason or if the mill just automatically does this.
I have attached my g-code, does anyone know why this is happening?

Thanks
Greg

[AUSTINMACHINING]

Could it be due to accel/Dece/rapid averaging into the feed rate ?. How are you determining the actual rate ?. Looking at the DRO screen ?.

[MichaelHenry]

I use SprutCAM to generate G-code for a Series I PCNC 1100 mill and it estimates the run time for each job. It is generally correct within a few seconds of the actual run time, even on jobs lasting 45 minutes with multiple tool changes so long as I tell it to use the *actual* rapid speed instead of the 500 ipm it uses as the default. Are you sure that your program is using the correct rapid speed?

Mike

[popspipes]

Hello!

I am trying to calculate the exact times that my PCNC 770 is cutting and the exact times when it is not.
I have some code that runs through the g-code which calculates the time based on my feedrate value.

The problem I am having is that the mill does not run at exactly the feedrate I input when it is executing a path. As in, when I enter a feedrate of 20 in/min in sprutcam it moves at 19.5 in/min in some cutting portions and at 21 in/min in others.

This screws up my calculations. I don't know if I am overlooking a command in my g-code that allows the tormach to compensate for some reason or if the mill just automatically does this.
I have attached my g-code, does anyone know why this is happening?

Thanks
Greg

I dont think an exact feedrate is possible, there is accel decel each time a line segment starts or stops, it will average the feedrate, It is this way in Mach and Pathpilot. As Mike says it will average out and be very close to actual but not exact.

[SCzEngrgGroup]

You will only hit the programmed feedrate during long-ish single-segment moves which are programmed as a single G1, G2 or G3. For most other moves, you'll have acceleration and deceleration occurring as the individual path segments are blended together by the "constant velocity" (a mis-nomer if ever there was one) mode. Sharp corners, in particular, will involve significant deceleration on entry, and acceleration on exit. Jobs programmed with a lot of short moves, and sharp turns can easily average well below the programmed feedrate.

Regards,
Ray L.

[gyronikeleg]

You will only hit the programmed feedrate during long-ish single-segment moves which are programmed as a single G1, G2 or G3. For most other moves, you'll have acceleration and deceleration occurring as the individual path segments are blended together by the "constant velocity" (a mis-nomer if ever there was one) mode. Sharp corners, in particular, will involve significant deceleration on entry, and acceleration on exit. Jobs programmed with a lot of short moves, and sharp turns can easily average well below the programmed feedrate.

Regards,
Ray L.

Thanks for all your responses.

When I run the program on my mill there is a field in the DRO that shows the actual feed rate. I created my g-code to do a 2D contour cut on a square and along the lengths of the square it stays at a constant speed of 19.5 in/min.

I removed all the rapid feed "G0" commands and replaced them with "G1" commands manually. When it is moving from cut to cut, the DRO says it is moving at a speed of 20 in/min, just when it is cutting the square it says 19.5 in/min.

All the speeds are constant, it appears, but they are not the constant speed i have input.

Greg

[ger21]

If you're using the parallel port, the actual speed can vary depending on the actual pulse rate for the PC you're using.

[R.DesJardin]

I do what Mike does and agree, I am trying to understand what a few seconds or even a minute makes?

[gyronikeleg]

I time the paths using a stopwatch and slowing the process down and calculated the feedrates at each path.

For the straightaways the average feed is almost exactly (+-.01 in/min) 5% less than my input feedrate of 20 in/min.

For the circular path the average feed is almost exactly (+-.01 in/min) my input feedrate of 20 in/min

[gyronikeleg]

I am trying to activate an arduino at +-.01 seconds within the time that the mill is on the cut path and when it is not.

So I want to turn it off right when the mill starts to move to another path, and then turn it off right when it starts another cut path.

[Steve Seebold]

Hello!

I am trying to calculate the exact times that my PCNC 770 is cutting and the exact times when it is not.
I have some code that runs through the g-code which calculates the time based on my feedrate value.

The problem I am having is that the mill does not run at exactly the feedrate I input when it is executing a path. As in, when I enter a feedrate of 20 in/min in sprutcam it moves at 19.5 in/min in some cutting portions and at 21 in/min in others.

This screws up my calculations. I don't know if I am overlooking a command in my g-code that allows the tormach to compensate for some reason or if the mill just automatically does this.
I have attached my g-code, does anyone know why this is happening?

Thanks
Greg

SO WHAT? Are you making hundreds of thousands of parts where tenths of a second count or are you making one or two parts where it would take you longer to correct the error than the time you would save. If you're running hundreds of thousands of parts, then you obviously bought the wrong machine.

[tmarks11]

Seems to me like you need to use M code embedded in you g-code to actuate your arduino at just the right time. That way you are not trying to time anything.

And then you need something like this:
Make Custom M-Codes with our USB IO Interface Module

[ger21]

Seems to me like you need to use M code embedded in you g-code to actuate your arduino at just the right time. That way you are not trying to time anything.

I don't think Mach3 will be anywhere near accurate enough (timing) using that method.

[tmarks11]

I don't think Mach3 will be anywhere near accurate enough (timing) using that method.

My point is that he wants to activate an arduino at some prices time along each cutting path, for an undisclosed reason.

Seems like he would be better off using M-code to activate it from the g-code that he is cutting with, cycling the it on and off at the end of each command segment. A PIA, but I don't think that he is going to be able to get it's cycling to coincide with the planned cut by using external timing.

I am trying to activate an arduino at +-.01 seconds within the time that the mill is on the cut path and when it is not. So I want to turn it off right when the mill starts to move to another path, and then turn it off right when it starts another cut path.

Unless he is talking about using the arduino to estimate cutting times. I don't think the OP has completely explained what he is trying to do.

[gyronikeleg]

My point is that he wants to activate an arduino at some prices time along each cutting path, for an undisclosed reason.

Seems like he would be better off using M-code to activate it from the g-code that he is cutting with, cycling the it on and off at the end of each command segment. A PIA, but I don't think that he is going to be able to get it's cycling to coincide with the planned cut by using external timing.



Unless he is talking about using the arduino to estimate cutting times. I don't think the OP has completely explained what he is trying to do.

I am trying to turn on an LED when it is cutting, and off when it is moving from cut to cut.

I would prefer to not have to babysit the program when it is running and manually turning the LED on and off. I have since figured out that G1 commands are reducing the feedrate by 5% the G3 G2 commands keep the programmed feedrate.
I dont know what would cause the G1 commands to slow down the feed, still trying to figure that out, if anyone has any idea why that would be that would be very helpful.

Thanks