G4 Dwell

Madocks · Aug 1, 2019

I am investigating the difference between a sub routine program drilling operation and a post processed drilling operation.

A hole drilled with sub routine took 88 seconds
A hole drilled with my post processed drilling operation took 52 seconds.

Both pecks are 0.3mm.

Same speeds, feeds, DOC, retracts etc.......

Seems to be inefficiencies in the subroutine.

Ive noticed the subroutine cycle is full of G4 F0.0 - my understanding this is a dwell of 0 seconds. Does a machine take any time to process this? on a 50mm stack it reads this command 166 times. Even If it added a fraction of a second this could all add up?

BSCustoms · Aug 1, 2019

If the code is in there the control has to read it. Though that seems like a huge difference. Can you take out that variable and try again?

angelw · Aug 1, 2019

Madocks said:
I am investigating the difference between a sub routine program drilling operation and a post processed drilling operation.

A hole drilled with sub routine took 88 seconds
A hole drilled with my post processed drilling operation took 52 seconds.

Both pecks are 0.3mm.

Same speeds, feeds, DOC, retracts etc.......

Seems to be inefficiencies in the subroutine.

Ive noticed the subroutine cycle is full of G4 F0.0 - my understanding this is a dwell of 0 seconds. Does a machine take any time to process this? on a 50mm stack it reads this command 166 times. Even If it added a fraction of a second this could all add up?

The time for the control to actually read a command is infinitesimal, in the whole scheme of things. The difference is the actual occurrence of the G04 Command (whether it's followed by the F0.0 address or not). G04 can be used to specify a dwell (specified with a dwell period), or when specified by itself, or a Zero dwell period, is used to initiate an Exact Stop, exactly the same as G09 (Exact Stop). When specified by itself, or with a Zero dwell period, the tool is decelerated at the end point of a block, then an in–position check is made. Then the next block is executed; hence the reason for the code including the G04 F0.0 taking longer.

Regards,

Bill

thunderskunk · Aug 1, 2019

angelw said:
...G04 can be used to specify a dwell (specified with a dwell period), or when specified by itself, or a Zero dwell period, is used to initiate an Exact Stop, exactly the same as G09 (Exact Stop). ..

Bill

One fairly clear way to test this would be to add a G09 to the beginning of your posted code, see if the times match.

Does your control only have the one canned peck drill cycle?

angelw · Aug 1, 2019

thunderskunk said:
One fairly clear way to test this would be to add a G09 to the beginning of your posted code, see if the times match.

Not really. G09 is only valid in the Block in which its specified. I made the comparison to G09 as G04 is also only valid in the Block in which its specified. G61 is the address for Modal Exact Stop. Specifying G61 at the start of the program would also not be a good comparison to use, as an exact stop would be executed on every axis move, not just the one currently affected by G04. The equivalent alternative would be to use G09 with each block influenced by G04.

Regards,

Bill

Matt G. · Aug 2, 2019

Maybe a dumb question, but I have seen G4 dwells with U,X, or P... never an F. Is the F format correct for your control, and if not is it defaulting to some dwell time other than 0?

PROBE · Aug 3, 2019

It wasn't mentioned which control is the machine equipped with. On Mitsubishi controls G4 is used to prevent look ahead. If this is the case, longer cycle time is obvious.

angelw · Aug 3, 2019

PROBE said:
It wasn't mentioned which control is the machine equipped with. On Mitsubishi controls G4 is used to prevent look ahead. If this is the case, longer cycle time is obvious.

Hello PROBE,
It would be useful to see the OP's Code, but given he is referring to what seems to be a long hand Peck Drilling Cycle, it would be a reasonable assumption that no two consecutive tool movements would be in the same direction, or at best, only two if the tool made a rapid movement to an R plane and then back to just clear of the previous hole depth. In this scenario, Look Ahead would have practically no affect and where each move is in the opposite direction to the one preceding it, absolutely no affect whatsoever.

1. Using Look Ahead Control (G08) on a test program of 4000 x 0.25mm linear moves all in the same direction, with a Feed Rate of 1000mm/min, will take one minute to execute.

2. Same program as 1., but with Look Ahead Control turned off, the program takes way longer. It was a long time ago when I tested this, so I can't recall the exact time. The results are somewhere in this Forum.

3. Using Look Ahead Control (G08) with the same number and size of move as in I and 2, but with each move in the opposite direction to the one preceding it (dithering + and - 0.25mm), the time taken to execute the whole program was exactly the same as the exercise in 2. above.

Accordingly, unless there is the opportunity for Acceleration/Deceleration (when consecutive moves are in a similar direction) to be optimized, Look Ahead affords no time saving.

Regards,

Bill

yardbird · Aug 3, 2019

Yeah I too think knowing the control and seeing the code would help. So when he says "sub routine" is he actually talking about a canned cycle? Or an actual G0 G1 longhand in a sub-program? My money goes on a G0 G1 F longhand program in the main body of the program as the quicker time opposed to the sub-program or canned cycle. It's my guess that is. I've never seen G4 with an F either it's always been U X & P.

Brent

PROBE · Aug 3, 2019

angelw said:
Hello PROBE,
It would be useful to see the OP's Code, but given he is referring to what seems to be a long hand Peck Drilling Cycle, it would be a reasonable assumption that no two consecutive tool movements would be in the same direction, or at best, only two if the tool made a rapid movement to an R plane and then back to just clear of the previous hole depth. In this scenario, Look Ahead would have practically no affect and where each move is in the opposite direction to the one preceding it, absolutely no affect whatsoever.

1. Using Look Ahead Control (G08) on a test program of 4000 x 0.25mm linear moves all in the same direction, with a Feed Rate of 1000mm/min, will take one minute to execute.

2. Same program as 1., but with Look Ahead Control turned off, the program takes way longer. It was a long time ago when I tested this, so I can't recall the exact time. The results are somewhere in this Forum.

3. Using Look Ahead Control (G08) with the same number and size of move as in I and 2, but with each move in the opposite direction to the one preceding it (dithering + and - 0.25mm), the time taken to execute the whole program was exactly the same as the exercise in 2. above.

Accordingly, unless there is the opportunity for Acceleration/Deceleration (when consecutive moves are in a similar direction) to be optimized, Look Ahead affords no time saving.

Regards,

Bill

Hi Bill, as usual I love your explanations, however on this anti-buffering topic we do have some disagreements.
Several years ago I wrote a special measuring program (this is what I mostly do) to be used on Haas machine. The program included about 50 lines long setup file. No movement commands, just assigning values to variables. As usual with Haas programs, I put the G103P1 statement at its beginning, to prevent the buffering. While checking the program I paid attention, that while this setup file is executed, I could observe on the screen the program "jumping" from line to line. It took quite a long time. I decided to add just to this file the G103P0 in the first line of this line, and tried the program again. The setup file has been read so quickly, I couldn't observe it on the screen. My conclusion: anti-buffering costs time, and if time subject is important, should be used accordingly.

angelw · Aug 3, 2019

PROBE said:
Hi Bill, as usual I love your explanations, however on this anti-buffering topic we do have some disagreements.
Several years ago I wrote a special measuring program (this is what I mostly do) to be used on Haas machine. The program included about 50 lines long setup file. No movement commands, just assigning values to variables. As usual with Haas programs, I put the G103P1 statement at its beginning, to prevent the buffering. While checking the program I paid attention, that while this setup file is executed, I could observe on the screen the program "jumping" from line to line. It took quite a long time. I decided to add just to this file the G103P0 in the first line of this line, and tried the program again. The setup file has been read so quickly, I couldn't observe it on the screen. My conclusion: anti-buffering costs time, and if time subject is important, should be used accordingly.

Hello PROBE,
Buffering relating to Macro Statements is a totally different story to Look Ahead for axis movement and I agree with you regarding Macro Statements. As I stated in my previous Post, it would be good to see the OP's Code,but typical of many Threads, the OP starts the Thread never to reply again, or respond to any suggestions made. I find this disappointing for the many new chums that may follow these Thread and not know if a fix to a problem was made. But time saving with regards to Look Ahead Blocks and Axis movement is exactly as I've explained it in my previous Post.

Regards,

Bill

angelw · Aug 3, 2019

Hello PROBE,
I've found the results of my test.

1. 20,000 x 0.05 moves one direction at F1000mm/min - G08 turned on:

a. Physical Feed Rate Achieved: F1000
b. Time Taken 1min.

2. 20,000 x 0.05 moves one direction at F1000mm/min - G08 turned off:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.66min.

3. 20,000 x 0.05 moves with each successive move in the opposite direction to the one preceding it (dithering 0.05 incrementally) at F1000mm/min - G08 turned off:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.66min. Exactly the same time as 20,000 x 0.05 moves one direction at F1000mm/min as per test 2

4. 20,000 x 0.05 moves with each successive move in the opposite direction to the one preceding it (dithering 0.05 incrementally) at F1000mm/min - G08 turned on:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.78min.

The slightly longer time resulting in test 4 compared to test 3 equates to 0.35miliseconds per move and may be due to the processing overhead of using one of the High Speed Tool Path functions. But that is only a hypothesis.

Regards,

Bill

PROBE · Aug 4, 2019

angelw said:
Hello PROBE,
I've found the results of my test.

1. 20,000 x 0.05 moves one direction at F1000mm/min - G08 turned on:

a. Physical Feed Rate Achieved: F1000
b. Time Taken 1min.

2. 20,000 x 0.05 moves one direction at F1000mm/min - G08 turned off:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.66min.

3. 20,000 x 0.05 moves with each successive move in the opposite direction to the one preceding it (dithering 0.05 incrementally) at F1000mm/min - G08 turned off:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.66min. Exactly the same time as 20,000 x 0.05 moves one direction at F1000mm/min as per test 2

4. 20,000 x 0.05 moves with each successive move in the opposite direction to the one preceding it (dithering 0.05 incrementally) at F1000mm/min - G08 turned on:

a. Physical Feed Rate Achieved: F375 max
b. Time Taken 2.78min.

The slightly longer time resulting in test 4 compared to test 3 equates to 0.35miliseconds per move and may be due to the processing overhead of using one of the High Speed Tool Path functions. But that is only a hypothesis.

Regards,

Bill

Hi Bill,
The case you brought is clear, and you are absolutely right. But Madock's case is different, I'm quoting: his " subroutine cycle is full of G4 F0.0".
In any case pity, that he did not present both: his post and the subroutine programs. It would be easier to evaluate what is going on.

Stefan

angelw · Aug 4, 2019

yardbird said:
Yeah I too think knowing the control and seeing the code would help. So when he says "sub routine" is he actually talking about a canned cycle? Or an actual G0 G1 longhand in a sub-program? My money goes on a G0 G1 F longhand program in the main body of the program as the quicker time opposed to the sub-program or canned cycle. It's my guess that is. I've never seen G4 with an F either it's always been U X & P.

Brent

Hello Brent,
Okuma, Siemems and others can use F to specify a dwell period in conjunction with G04. Siemens use the S address if the Dwell is to be in terms of Spindle Revolutions; most other controls use Incremental Mode with G04 for that purpose. Fagor controls use K to specify a dwell period, so its not unusual to see addresses other than X, U, or P being used.

In all cases, G04 specified without a specified dwell period, or a Zero period, will be used to execute Exact Stop. In the OP's example an F0.0 is used, so the control is probably not a Fanuc, Mitsubishi, Haas or the magnitude of other controls that don't use F to specify a dwell. However, the inclusion of the F address with G04 with any of these controls won't constitute a Syntax Error per se. If a command such as G04 F0.0 was specified with a Fanuc control, the G04 would be executed as an Exact Stop Command (with no Dwell) and the F address would set the Modal Feed Rate to Zero. No Syntax Error would be raised and no Default Dwell period would be executed.

Regards,

Bill

Search

Largest Manufacturing Technology Community on the Web

Search

G4 Dwell

Madocks

Plastic

BSCustoms

Cast Iron

angelw

Diamond

thunderskunk

Cast Iron

angelw

Diamond

Matt G.

Aluminum

PROBE

Hot Rolled

angelw

Diamond

yardbird

Titanium

PROBE

Hot Rolled

angelw

Diamond

angelw

Diamond

PROBE

Hot Rolled

angelw

Diamond

Similar threads