Slicing

From 3D printer from scratch
Revision as of 05:08, 3 September 2018 by Sensille (talk | contribs) (Sensille moved page Mathematics to Slicing without leaving a redirect)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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