http://3dpfs.sensille.com/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=&size-mode=max&size=03D printer from scratch - New pages [en]2024-03-28T10:23:19ZFrom 3D printer from scratchMediaWiki 1.30.0http://3dpfs.sensille.com/index.php?title=MathematicsMathematics2018-09-03T05:28:51Z<p>Sensille: /* Current (lacking) Solution */</p>
<hr />
<div>== Requirements for the Controller ==<br />
<br />
* The head has to be moved along a given curve. Currently the curve consists of segments of lines, clothoids and arcs. Later on they may also be described by Bezier-Splines/B-Splines/NURBS.<br />
* The movement speed is independent from the parameterization of the curve. Most of the time the head is required to move at constant |v|, but it also accelerates/decelerates.<br />
* Head movement has to be continuous in position, speed and acceleration and bounded in jerk. The source curves are at least <math>C^2</math>.<br />
* The path the head is moved along should not deviate from the given curve by more than 0.01mm, total range is 300mm. So an accuracy of <math>10^{-5}</math> is striven for.<br />
* The velocity of the head should not deviate by more than <math>10^{-4}</math>, the acceleration has to be continuous and bounded, the jerk only has to be bounded.<br />
* The motor controller is implemented in an FPGA and communicates with the host via UART.<br />
* Required step frequency up to 6 MHz, FPGA running at 20MHz.<br />
* The solution should accommodate multiple kinematics, like cartesian, corexy, delta and polar.<br />
<br />
== Current (lacking) Solution ==<br />
<br />
Currently the controller accepts commands of tuples of jerk values for each axis along with a duration. Velocity and acceleration initially start at zero and are maintained between commands. This is good for straight lines with s-curve motion profiles, but to follow a curve tightly many control commands would be necessary, overwhelming the host and the communication interface.<br />
<br />
Commands are queued so that they can be executed back-to-back.<br />
<br />
== Possible Solution ==<br />
<br />
If the controller would implement a 5th order polynomial, each control command would consist of a tuple of (jerk, snap, crackle) per axis and a duration, while again velocity and acceleration start at zero and are maintained between commands. This would allow the controller to control the movement of the head up to jerk, while approximating the curve with a 2nd order path. The resulting motion would be continuous up to acceleration, while between segment jerk, snap and crackle can jump.<br />
<br />
To derive the parameters one would partition the curve into segments, calculating position, velocity and acceleration on start and end point. These 6 values determine exactly all parameters and ensure that the resulting path is <math>C^2</math>.<br />
<br />
The segments could be evenly spaced in terms of arc length or varied depending on the sharpness (change of curvature) of the curve. This is very easy for lines, arcs and clothoids as they are already parameterized in arc length, whereas for splines it would be necessary to approximate the arc length numerically.<br />
<br />
Note that the source curve is two dimensional, while the controller commands are per axis. Velocity and acceleration information are provided seperatly.<br />
<br />
One advantage of this solution is that there is no curve fitting necessary, because at the end of each segments the exact values of position, direction, velocity and acceleration are met.</div>Sensillehttp://3dpfs.sensille.com/index.php?title=Controller_v2Controller v22018-06-10T18:38:40Z<p>Sensille: /* SET_ROUTING */</p>
<hr />
<div>= UART-based Controller =<br />
<br />
The controller has two UARTs, one for control and one for motion data. The motion-UART can use hardware flow control.<br />
<br />
== Framing ==<br />
<br />
The framing is self synchronizing. Each frame ends with an EOF marker. Everywhere else the EOF marker is escaped.<br />
<br />
=== Frame Format ===<br />
<br />
* 1 byte sequence number<br />
* n byte frame data<br />
* 2 byte crc16 (CCITT) of frame data<br />
* 0x7e as EOF marker<br />
<br />
=== Escaping ===<br />
<br />
Escaping is done by byte stuffing. Escape character is 0x7d. Bytes to be escaped are 0x7d and 0x7e. The escape character is following by the byte to by escaped XOR 0x20.<br />
<br />
=== Sequence Number ===<br />
<br />
The sequence number is echoed by the controller. The controller expects sequence numbers in ascending order. The sequence number has 7 bits. The special sequence nuber 0x80 resets the expected number in the controller to 0, so that the next frame has to be sent with the number 0x01. This is needed to achieve a resynchronization.<br />
The controller signals a receive error by setting the MSB in the response sequence number, echoing the received number.<br />
<br />
== Control Commands ==<br />
<br />
<vardata> is an 8-120 bit unsigned integer. If less than 120 bit are sent, the date is 0-extended to 120 bit.<br />
<br />
=== SPI ===<br />
<br />
Format: 0x8X <vardata><br />
<br />
Sends <vardata> to SPI, asserting CS X. The read data are sent in a response packet of full length.<br />
<br />
=== GPOUT_HI ===<br />
<br />
Format: 0x70 <X><br />
<br />
Sets GPIO X to HI.<br />
<br />
=== GPOUT_LO ===<br />
<br />
Format: 0x71 <X><br />
<br />
sets GPIO X to LO.<br />
<br />
=== GPIN ===<br />
<br />
Format: 0x78<br />
<br />
Sends the value of all GPIN-pins as a bitmask in a response packet.<br />
<br />
== Motion Commands ==<br />
<br />
<vardata> is an 8-64 bit signed integer. If less than 64 bit are sent, the date is sign extended to 64 bit.<br />
<br />
=== SET_ROUTING ===<br />
<br />
Format: 0x60 <output channel> <controller source><br />
<br />
Controllers are numbered here starting from 1. Setting the controller to 0 means disabling the output.<br />
<br />
=== NOTIFY ===<br />
<br />
Format: 0x61 <vardata><br />
<br />
Echoes <vardata> to host as full 64 bit value.<br />
<br />
=== LOADALLREGS ===<br />
<br />
Format: 0x70 <vardata><br />
<br />
Load all preload registers to vardata.<br />
<br />
=== LOADCNT ===<br />
<br />
Format: 0x71 <vardata><br />
<br />
Load the count register to vardata and latch all registers with the preload registers.<br />
<br />
=== LOADREG ===<br />
<br />
Format: 0x8X <vardata><br />
<br />
Load the preload register belonging to controller X with vardata.</div>Sensillehttp://3dpfs.sensille.com/index.php?title=MathematicsMathematics2018-06-03T10:00:20Z<p>Sensille: Sensille moved page Mathematics to Slicing without leaving a redirect</p>
<hr />
<div>= Transformation Chain =<br />
<br />
== Input ==<br />
* STL<br />
* STEP<br />
<br />
== Slicing output ==<br />
* lines<br />
* arcs<br />
* b-splines<br />
<br />
=== Options ===<br />
* approximate everything with lines (gcode)<br />
* approximate everything with bezier splines<br />
<br />
== Adding velocity profile ==<br />
* trapezoidal<br />
* s-curve<br />
* higher order<br />
<br />
== Transform into target kinematics ==<br />
* cartesian<br />
* corexy<br />
* delta<br />
* polar<br />
<br />
=== Options ===<br />
* transform mathematically<br />
* 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<br />
<br />
== Generate per-axis motion data ==<br />
* either mathematically<br />
* or step data<br />
<br />
== Transfer per-axis motion data ==<br />
* transfer mathematically<br />
* transfer ((lossily) compressed) step data<br />
<br />
== Generate steps ==<br />
<br />
= Potential Solutions =<br />
<br />
<br />
== Most complex solution: Transport mathematically correct data up to the fpga ==<br />
* transformations for lines, arcs and splines needed into target kinematics<br />
* projections into single axis and combination with velocity profiles for each transformation needed<br />
* fpga needs to know all projected profiles<br />
<br />
== Intermediate solution: Approximate at or after slicing and transport mathematically ==<br />
* only one motion (lines or splines) need to be translated into all target kinematics<br />
* fpga need to know one profile for each kinematics<br />
<br />
== Simplest solution: Approximate at or after slicing ==<br />
* only points need to be translated to target kinematics<br />
* computationally intensive because each point needs to be translated individually, plus needed oversampling for some kinematics<br />
* steps need to be compressed for transmission. If the compression is lossy, it degrades the precision slightly</div>Sensille