# Slicing

Revision as of 05:08, 3 September 2018 by Sensille (talk | contribs) (Sensille moved page Mathematics to Slicing without leaving a redirect)

# Transformation Chain

## Input

- STL
- STEP

## Slicing output

- lines
- arcs
- b-splines

### Options

- approximate everything with lines (gcode)
- approximate everything with bezier splines

## Adding velocity profile

- trapezoidal
- s-curve
- higher order

## Transform into target kinematics

- cartesian
- corexy
- delta
- polar

### Options

- transform mathematically
- quantize into oversampled steps before transformation and translate only points Oversampling may depend on the target kinematics and must be high enough that after transformation the resolution still exceeds the microstepping resolution

## Generate per-axis motion data

- either mathematically
- or step data

## Transfer per-axis motion data

- transfer mathematically
- transfer ((lossily) compressed) step data

## Generate steps

# Potential Solutions

## Most complex solution: Transport mathematically correct data up to the fpga

- transformations for lines, arcs and splines needed into target kinematics
- projections into single axis and combination with velocity profiles for each transformation needed
- fpga needs to know all projected profiles

## Intermediate solution: Approximate at or after slicing and transport mathematically

- only one motion (lines or splines) need to be translated into all target kinematics
- fpga need to know one profile for each kinematics

## Simplest solution: Approximate at or after slicing

- only points need to be translated to target kinematics
- computationally intensive because each point needs to be translated individually, plus needed oversampling for some kinematics
- steps need to be compressed for transmission. If the compression is lossy, it degrades the precision slightly