Canned cycles and subroutines

[aldenhart]

(From the synthetos TinyG forum at https://www.synthetos.com/topic/g83-canned-cycle-applicable-to-other-canned-cycles/)

I’ve been thinking about how to program canned cycles, apparently while I was sleeping. I thought I would get this out there before I lost it. I’ve gone ahead and started a new thread for the canned cycles. I hope to add to this to this if anyone is interested. I’ve not began looking at the TinyG code yet, but maybe this weekend, or if I get enough cycle time tonight. (Running a big 2 pallet horizontal mill with Fanuc control, 80x65x47 inches working envelope)

Generic G83 peck drill cycle:

N10 G0 G90 G54 X1.0 Y1.0 Z1.0 ; N20 G83 X1.0 Y1.0 Z-0.25 R0.1 Q0.1 F5.0 (X AND Y NOT REQUIRED, CAN BE PULLED FROM CURRENT POSITION) ; N30 X-1.0 Y1.0 (Y LOCATION NOT REQUIRED); N40 Y-1.0 (X LOCATION NOT REQUIRED); N50 X1.0 ; N60 G80 ;

This drills a 2.0 bolt square about G54 X0 Y0. (Yah, those are inches I’m using, you’ll pry my inches from my cold dead hands)

I’ve written some pseudo code for this, please excuse irregularities, general ugliness, syntax/grammar foulness. I’m not very good at programming and use the lots of monkeys with typewriters method. Also the sledgehammer method. Probably about clear as mud. Pseudo code:

Canned cycle sub called passing vars from call //G83 X1.0 Y1.0 Z-0.25 R0.1 Q0.1 F5.0//

While Line != G80 //quit when G80 is reached// If Line has X Then store X in canned_X Else store current_X in canned_X End If

If Line has Y Then store Y in canned_Y Else store current_Y in canned_Y End If //More of these type statements could be added for ABC axii//

Output “G0 X(canned_X) Y(canned_Y) ;” //moves to first hole location or goes to where it already is//

G83 sub called and passes (R Q z F) //G83 sub peck drills the hole//

   store current_Z in traverse_Z  //this is where it could be changed for G98,G99 function//
   Output “G0 Z(R) ;” //moves to rapid plane//
   drilled_distance = R  //we start drilling here//

  While Z != drilled_distance  //when drilled_distance is the same as Z we are done//

     drilled_distance = drilled_distance – Q  //start subtracting pecks from drilled_distance//

     If drilled_distance < Z  //We don’t want to drill deeper than Z so reset number to max Z depth//
        Then drilled_distance = Z
     End If

     Output “G1 Z(drilled_distance) F(F) ;” //drill a peck//
     Output “G0 Z(R) ;” //peck back out to Z0.1 in this example//

     If drilled distance != Z  // We don’t want to go back into hole if already gone to depth //
        Then Output “G0 Z(drilled_distance + .01) ;” //rapid back into hole .01 above last drilled depth//
     End If                                                                   //the .01 would generally be a peck return parameter set elsewhere like EEPROM//
Loop While //Get ready for the next peck or quit//

Output “G0 Z(traverse_Z) ;” //move back up to our intial Z, Z1.0 in this case// End G83 sub

Grab next line of program //get ready to drill the next hole or quit// Loop While

End canned

Basically this takes the parameters from the G83 line and following lines until the G80. It converts this into G0′s and G1′s. G17 is assumed, and does not take into account G18 and G19. This also does not provide for G98 and G99. Bad things would happen if in G91 mode and not G90.

Probably be best to convert all this to machine co-ords but not sure if that function is present, think I read that it wasn’t yet.

Output would look like this for the first hole:

G0 X1.0 Y1.0 G0 Z0.1 G1 Z0.0 F5.0 G0 Z0.1 G0 z0.01 G1 Z-0.1 F5.0 G0 z0.1 G0 z-0.09 G1 z-0.2 F5.0 G0 z0.1 G0 z-0.19 G1 z-0.25 F5.0 G0 z0.1 G0 z1.0

On to next hole.

Again, this is just a rough idea but I would appreciate any input. Or tell me to get off your lawn.

[aldenhart]

Some thoughts.

First, machine (absolute) coordinates are implemented (G53), as are 6 work coordinate systems, G54, G55, G56, G57, G58 and G59. G92 offsets are also implemented as proper G92, G92.1, G92.2 and G92.3 as per Kramer (NIST RS274NGC-V3) If you remember where you read that machine coordinates are not available I'd appreciate a pointer. Sounds like the wiki has inconsistent data and I'd like to fix that. Otherwise I'll just hunt for it. Time for a revision pass anyway.

You are actually calling for 2 things in your code: canned cycles (like G83), and subroutines, or O codes in LinuxCNC (EMC2) speak. (http://linuxcnc.org/docs/html/gcode/o-code.html)

Canned cycles (G81-G89 + G38.2 probes) are anticipated but to date the only thing that resembles a canned cycle is the homing cycle. Here's what would have to happen in the code to add a new canned cycle (for when you get to looking at the code)

• Add the G code and its parameters in gcode_parser.c. In the case of G83 Q word would also have to be added - this is not already in the Gcode model. That would need to be added to the GcodeModel and GcodeInput structures in canonical_machine.h
• Next a canned cycle should be added as a canonical machining function in canonical_machine.c/.h. This should call the actual cycle that would probably be in its own file, something like cycle_g83peck_drill.c. You can look at cycle_homing.c for an example of how this might work.
• The controller in controller.c handles blocking and threading using a state machine as implemented in _controller_HSM() in controller.c. Essentially it starts the main loop at the lowest level of blocking (i.e. the highest priority routine) and continues down the list until a function would block. No actual blocking is allowed, so the function returns a "busy signal" (EAGAIN code). This causes the main loop to restart. For this to work the functions that would block need to be coded as continuations. Continuations are functions that are split into 2 parts - the part that gets called initially- which runs some init code and sets up some memory variables, then the continuation "callback" that gets called from the main loop. The cycles need to go into the right part of the main loop - in this case right under the homing callback. See the following for more details: https://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Module-Details#controller.c.2F.h https://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Module-Details#How_To_Code_Continuations

O codes (subroutines) are more complicated. I've thought about this for some time now but have not bitten the bullet on this. There are at least 3 new things that need to be added for this to work. (1) subroutines and conditionals, (2) parameters, and (3) expressions. See the EMC O code page for how they implemented this. I've been careful to not step on the characters needed for expressions, so they are still available for use in Gcode lines. Parameters are a challenge for an embedded system with limited memory. They are doable, but there won'e be 5999 of them - not enough memory. Some form of sparse mapping will be required. Hopefully I'll be able to attack this at some point, but there are a lot of other things that should probably get done first. Just having canned cycles would be a help even if there were no subroutines.

[em]

Probing (edge finding, center finding) using the existing switches would be unbelievably awesome. Any idea when you might get back to this? : )

[aldenhart]

We have simple, straight probing (G38.2) in test right now in the edge branch. Once that's settled we can worry about center finding and other more complex probes.

[em]

Yay! Can't wait to throw my silly mechanical edge finder in the junk bin. Glad to hear you managed scope this monster of a task down a little.