ESPels icon indicating copy to clipboard operation
ESPels copied to clipboard

threading without a compound use case for work offsets

Open jschoch opened this issue 1 year ago • 1 comments

image

There are multiple threading strategies available, this focuses single sided with variable depth starting from a Z+

  1. user configures lathe in start position (G54.1 "0"), with enough lead to remove any acceleration errors
  2. User inits threading dialog in UI
  3. Dialog asks for thread parameters
  4. User enters parameters: first thread depth, thread length (how far in Z to cut the thread), handedness, number of starts
  5. Dialog calculates number of passes, depth per pass, and offset required to simulate the compound,
const passes = () => {
    let p = Math.ceil(Math.pow(((config.pitch * 0.614) / firstThreadDepth),2));
    if(Number.isInteger(p)){
      return p;  
    }else{ return 0}
  }

fir (var current_pass=1; i <= number_of_passes; i++){
 feed = (thread_depth/Math.sqrt(number_of_passes -1)) * Math.sqrt(current_pass-1);
  1. outputs a table
  2. User confirms by clicking start

This is where it is a bit tricky because we depend on the user to feed X in and out, and the lathe is likely small and not very rigid, we may need to run the same depth more than one time. This is where I want to use the offsets.

pitch: 1.5mm Thread Depth: 0.921 Recommended Passes: 22Initial Offset: 0.2 Offset per pass 0.06818181818181818

pass 1: the offset is the starting position, nothing really needs to be done here other than the operator moving the X pass 2: first offset. Dialog confirms pass 1 complete, then stores the original offset, we'll call that G54.1, the machine then creates a new offset G54.2 offset in Z- by the calculated amount (.068mm) and changes to use that offset.

if the user wants to change back to the original offset they can select the pass "#" from the UI.

pass 3: same as pass 2 but uses G54.3 to store the new offset

for multiple starts we'd could make an offset of offsets, but likely not worth it to so this abstraction.

...

finish: delete offsets from threading or leave them in there?

We could also add some backlash compensation to ensure the lead screw slack is removed before the thread feeding starts.

so, we'd need


// 1. doubt this needs to be int64_t
// 2. if we do this in steps need to ensure everything from/to the UI is in steps
int64_t offset[3]

home instance //  position at machine start.  This is tricky because you frequently move everything around with the half nut and this may quickly become meaningless
float backlash.z, backlash.x
offsets[20] // ? not sure what a good number is but there is plenty of memory available
uint_8_t current_offfset // offsets index
uint_8_t last_offset // offsets index
double offset_in_mm( offset_3 ) // function to translate steps to mm

@digiexchris let me know if this is clear enough for you.

jschoch avatar Mar 03 '23 14:03 jschoch