Difference between revisions of "Slicing"
(Created page with "Input ===== - STL - STEP Slicing output ============== - lines - arcs - b-splines Options: - approximate everything with lines (gcode) - approximate everything...") |
m (Sensille moved page Mathematics to Slicing without leaving a redirect) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | = 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 | + | == 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 | + | == 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 | + | == 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 | + | == 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 | |
− | |||
− |
Latest revision as of 05:08, 3 September 2018
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