Updates:
20mm cubes of several Triply Periodic Minimal Surfaces (TPMS) as explored at Generative Parametric Infill Geometries printed with MSLA (Anycubic Photon Mono 4K) at 35 μm XY, 50 μm Z:
Most of the cubes were printed without support, the cylindrical and spherical projections required supports.
Updates:
The past years I focused on Filament Deposition Manufacturing (FDM) / extrusion based 3D printing, and the time came to focus on MSLA resin based process as well.
My main use case a small pieces, like custom pulleys and idlers – precise parts, such as:
The Anycubic Photon Mono 4K seemed like a good choice to start with:
| SLA Stereolithography – one beam/point light source | MSLA Mask Stereolithography Aparatus – one light source, masking what does not need to be printed | DLP Digital Light Processing – one image, each pixel controlled by micro mirror |
I ordered 2022/11/22 for EUR 170 and received it 4 days later via Anycubic Store within Amazon, along with a few utilities like water wash resins, gloves, etc – ready to MSLA print.
| FDM/FFF | Resin MSLA |
|---|---|
| X, Y precision: 100μm Z precision: 50μm minimal structure: 200-600μm1) minimal post-processing minimal toxicity of filament print duration based on printed volume large scale prints affordable 1kg filament EUR 15-30 mixed materials2) | X, Y precision: 35-75μm Z precision: 30-50μm minimal structure: 30-50μm extensive post-processing severe toxicity of resin print duration based on print Z height only large scale prints require expensive printers 1kg resin EUR 30-803) single material |
My development environment is Linux, and as of 2022/11 there is no Linux Photon Workshop, the name of the slicer needed to slice for Mono 4K; but you can run it via Wine (a Windows compatibility wrapper):
% wine AnycubicPhotonWorkshop_V2.2.19_x86.exeand afterwards it is available direct at:
% wine ~/.wine/drive_c/Program\ Files\ \(x86\)/AnycubicPhotonWorkshop/AnycubicPhotonWorkshop.exeI tried my xyzHollowCalibrationCubeV2 and used auto hollow feature which defaults to 2mm thickness:
This seems to work but is not ideal. The Photon Workshop reveals that Photon Mono 4K supports only .pmwa format, which as it turns out, is PWS format just with the extension .pmwa to avoid mixing up different PWS files for different machines, as the pixel-based slices are hardware dependent now as resolution of the display is set.
Chitubox Slicer is available for Linux natively and supports a variety of SLA printers, also the Mono 4K:
I also used the auto hollow feature, which defaulted to 1.2mm wall thickness.
I ended up with the Lychee Slicer which is available for Linux as well, which contains some annoying advertising to wait for when slicing or exporting various formats, but functionality-wise it it is more intuitive than Chitubox Slicer.
As mentioned, the Photon Mono 4K has its own proprietary file-format PWS file to print with, with a particular file extension to indicate which Anycubic MSLA device it is sliced for:
| Machine | File Extension | Layer Image Encoding |
|---|---|---|
| Mono | PWNO | PW0 |
| Mono SE | PWMS | PW0 |
| Mono X | PWMX | PW0 |
| Mono X2 | PMX2 | PW0 |
| Mono 4K | PWMA | PW0 |
| S | PWS | PWS |
| Zero | PW0 | PW0 |
| X | PWX | PW0 |
| Ultra | DLP | PW0 |
| D2 | DLP2 | PW0 |
Prusa Slicer slices also for MSLA, it’s own .sl1 format, just a ZIP file with a list of PNG files per slice, in order to convert .sl1 to PWS/.pwma another tool is required:
.pw*) file-formats.photon with SL1toPhoton command line tool, and extend functionality to support PWS/.pwma as well.pwma.photon (and ctb/cbddlp) is an older file format, whereas newer Photon Workshop (PW) has PWS and PW0 encoded images as layers – so far the format seems reverse engineered and somewhat documented via UVTools: PhotonWorkshopFormat.cs
| Manufacturer | File Extension | FIle FOrmat |
|---|---|---|
| Anycubic Photon Mono | .pw* | PWS/PW0 |
| Anycubic Photon | .photon | alike CTB |
| Elegoo Mars | .ctb | CTB/CBDDLP |
| Creality LD002 | .ctb | CTB/CBDDLP |
| Phrozen | .phz | CTB/CBDDLP |
Some deeper dive into the available metadata of PWS vs SL1 format:
| PWS (header) | SL1 (prusaslicer.ini) |
| “xy_pixel”: 35.0, “z_thickness”: 0.05000000074505806, “exposure_time”: 2.0, “off_time”: 0.5, “bottom_layers_exposure_time”: 40.0, “bottom_layers”: 6.0, “z_lift_height”: 6.0, “z_lift_speed”: 4.0, “z_drop_speed”: 6.0, “total_volume”: 4.853200912475586, “antialiasing_grade”: 1, “x_resolution”: 3840, “y_resolution”: 2400, “weight”: 0.0, “price”: 1.067704200744629, “resin_type”: 36, “layers_count”: 400 | “absolute_correction”: “0”, “area_fill”: “50”, “bed_shape”: “0x0,120×0,120×68,0x68”, “bottle_cost”: “0”, “bottle_volume”: “1000”, “bottle_weight”: “1”, “display_height”: “68”, “display_mirror_x”: “1”, “display_mirror_y”: “0”, “display_orientation”: “portrait”, “display_pixels_x”: “2560”, “display_pixels_y”: “1440”, “display_width”: “120”, “elefant_foot_compensation”: “0”, “elefant_foot_min_width”: “0.2”, “exposure_time”: “10”, “faded_layers”: “10”, “fast_tilt_time”: “5”, “gamma_correction”: “1”, “hollowing_closing_distance”: “2”, “hollowing_enable”: “0”, “hollowing_min_thickness”: “3”, “hollowing_quality”: “0.5”, “initial_exposure_time”: “15”, “initial_layer_height”: “0.3”, “layer_height”: “0.3”, “material_correction”: “1,1,1”, “material_correction_x”: “1”, “material_correction_y”: “1”, “material_correction_z”: “1”, “material_density”: “1”, “material_print_speed”: “fast”, “max_exposure_time”: “100”, “max_initial_exposure_time”: “150”, “max_print_height”: “200”, “min_exposure_time”: “0”, “min_initial_exposure_time”: “0”, “output_filename_format”: “[input_filename_base].sl1”, “pad_around_object”: “0”, “pad_around_object_everywhere”: “0”, “pad_brim_size”: “1.6”, “pad_enable”: “1”, “pad_max_merge_distance”: “50”, “pad_object_connector_penetration”: “0.3”, “pad_object_connector_stride”: “10”, “pad_object_connector_width”: “0.5”, “pad_object_gap”: “1”, “pad_wall_height”: “0”, “pad_wall_slope”: “90”, “pad_wall_thickness”: “2”, “printer_technology”: “SLA”, “relative_correction”: “1,1”, “relative_correction_x”: “1”, “relative_correction_y”: “1”, “relative_correction_z”: “1”, “slice_closing_radius”: “0.049”, “slicing_mode”: “regular”, “slow_tilt_time”: “8”, “support_base_diameter”: “4”, “support_base_height”: “1”, “support_base_safety_distance”: “1”, “support_buildplate_only”: “0”, “support_critical_angle”: “45”, “support_head_front_diameter”: “0.4”, “support_head_penetration”: “0.2”, “support_head_width”: “1”, “support_max_bridge_length”: “15”, “support_max_bridges_on_pillar”: “3”, “support_max_pillar_link_distance”: “10”, “support_object_elevation”: “5”, “support_pillar_connection_mode”: “dynamic”, “support_pillar_diameter”: “1”, “support_pillar_widening_factor”: “0”, “support_points_density_relative”: “100”, “support_points_minimal_distance”: “1”, “support_small_pillar_diameter_percent”: “50%”, “supports_enable”: “1” |
Notes:
xy_pixel dictates square pixelsx_resolution & y_resolution with xy_pixel give actual build arealayers_count * z_thickness, assuming equal layer heights| PWS | SL1 |
|---|---|
| x_resolution [px] | display_pixels_x [px] |
| y_resolution [px] | display_pixels_y [px] |
| xy_pixel [μm] | display_pixels_x / bedshape[x] * 1000 [μm] |
| layers_count | len(<*.png>) |
MSLA resin printers are quite closed systems without much information of the hardware, firmware, and additional having their own proprietary file formats which contain the layer images.
For the Anycubic Photon Mono 4K is an open source firmware available, Turbo Resin – which gave me a good reason to get this 3D printer. Along with it, the hardware has been pretty much reversed engineered.
| Anycubic Firmware | Turbo Resin (2022/12) |
|---|---|
| – PW0/PWMA format | – PW0/PWMA & CTB format |
Pondering on a custom MSLA slicer:
| Feature | Prusa Slicer | Lychee Slicer | ChituBox Slicer |
|---|---|---|---|
| command line interface (CLI) | Y | – | – |
| automatic hollowing | Y | Y | Y |
| drain holes | Y | Y | Y |
| automatic support | Y | Y | Y |
| Linux support | Y | – | – |
| PWS support | – | Y | Y |
Unfortunately there is no open (M)SLA format, each manufacturer kind of does its own, whereas G-code .gcode has some conformity, although G-code in general is also machine specific has it has absolute positioning, which differ from machine to machine, but at least G-code is easy to compose unlike proprietary (M)SLA file formats.
SL1 format by Prusa Engineering is a simple ZIP file which contains:
config.ini: irrelevant infoprusaslicer.ini: info about printer (bed size), pixel density, and many slicer settings*.png: enumerated image files per slice in PNG formatand thereby is open enough for my taste.
After many weeks postponing, as I wasn’t eager deal with the inherent messiness of resin printing, I gave it a shot with some of the Triply Periodic Minimal Surfaces (TPMS) (2023/03/05):
The Lychee Slicer gave 1h 15m print time, the printer itself showed 2h 15m; I used Anycubic White Water Wash Resin. I used automatic supports, and it printed 5 pieces successful, 3 pieces failed and only apprx. 4mm Z height were printed, interestingly all 3 failed pieces failed at the same Z height and broke off and stuck at the print plate.
I reprinted the 3 failed pieces at the same place, and this time they succeeded – which is strange as I suspected perhaps uneven light or some other positional inconsistency, but obviously the position did not matter, which is bad as I don’t know what caused the first failed print.
The curved bottoms (not directly printed but with diverse support pipes) already showing severe distortion while printing.
Update: It seems my office rooms aren’t warm enough, so the bed adhesion isn’t optimal as I read up in some forum posts. I tried to print a few other pieces, all failed the next day in the room with 15-19C° – the prints detached after 2-3mm height from the build plate. I moved it to another warmer room, warmed the resin on the radiator which helped.
The overall quality of the pieces is astonishing, no visible voxels or layers are seen, incredible quality for those prints which didn’t fail.
Yet the failure rate is still significant for my taste, so I need to pay close attention to room temperature, and other aspects:
The cause of the “delimination” isn’t clear yet to me, it seems the prints with proper support and elevated bottom printed better, but I need to confirm with more prints.
More photos you find at MSLA printing Triply Periodic Minimal Surfaces (TPMS).
As a start I assembled a simple DIY curing station with a 5m UV LED strip and placed it inside a plastic cup, with some aluminium foil at the bottom and top lid:
I only cure for 4-5mins, longer exposure changes the white resin into yellowish tint, and indicates over curing.
After a print, the resins needs to be filtered for impurities, such as partial cured pieces not attached to the part, with a funnel and filter into a cup or bottle, and then it can be poured back into the vat ready to print again.
One can leave the resin in the vat for weeks, if you stir the resin short before you print again – stirring the resin within the vat is not ideal, as one has to avoid to scratch or FEP film; yet there is no need to pour resin back into the bottle unless one changes the resin, like the brand or color.
I remixed an existing drip hook for Photon Mono to fit Photon Mono 4K, and make it easier to slide the bed on and off.
Download
Additionally I’ve got a spring steel build plate 135x80mm with a magnetic base for EUR 10 (2022/12).
This turned out to be a good choice, the removal of the pieces is easy without additional tool.
Caution:
After a few days I aimed for the main use case of mine: printing custom pulleys.
As I printed them with Anycubic Water Wash White Resin without support, the “elephant foot” comes from the first 6 layers being cured for 40s as in my case, and the UV light refracting and curing more than meant to be, but I can neglect this.
| MSLA | FDM/FFF | |
| geometrical accuracy | ★★★★☆1) | ★★★☆☆ |
| surface quality | ★★★★☆ | ★★☆☆☆ |
| mechanical sturdiness | (not yet tested) | ★★★☆☆ (PLA) |
| print time per piece | 5m 30s2) | 15m |
| print time for 1 piece | 1h 30m | 15m |
| print time for 16 pieces | 1h 30m | 4h |
My own experience with different resins (to be extended):
| Defaults V0.0.11 Firmware V0.11 | Defaults V2.0.2 Firmware V0.16 | White WATER WASH RESIN (Anycubic) | Clear Water Wash Resin (Resione) | |
|---|---|---|---|---|
| Layer Thickness [μm] | 50 | 50 | 50 | 50 |
| Exposure Time [s] | 3 | 2.5 | 3 | 2 .. 3 |
| Exposure Off Time [s] | 2.5 | 1 | 0.5 | 0.5 |
| Bottom Exposure [s] | 50 | 30 | 40 | 40 |
| Bottom Layers | 6 | 6 | 6 | 6 |
| Anti-alias | 1 | 1 | 1 | 1 |
| Z Lift Distance [mm] | 3.0 | 4.0 | 6.0 | 6.0 |
| Z Lift Speed [mm/s] | 1.0 | 1.0 | 2.0 | 1.0 |
| Z Retract Speed [mm/s] | 1.0 | 1.0 | 4.0 | 1.0 |
| UV Power [%] | 100 | 100 | 100 | 50 .. 100 |
| Notes | Distance, Speed & Retract Speed for – [BL] Bottom Layers – [NL] Normal Layers individually definable | – geometrical precise | – soft with 3s exposure – stiffer & brittle with 5s exposure – geometrical not precise (+0.2 .. 0.8mm in XYZ) |
Pros:
Cons:
Confusing:
It’s a low-cost entry level MSLA machine, Anycubic seems to care little about the software (2023/03) as the slicer as well the firmware are Minimal Viable Product (MVP) level, but aren’t mature or reliable at all. Given they sell 500K+ machines per year at least, investing to improve in the firmware would help 500,000 users.
Anycubic Photon Mono 4K specific:
General Photon Series MSLA:
MSLA Slicers:
Updates:
As I progress I will update this blog-post.
Infill geometries are geometries which are continuous, repetitive or periodic; they fill a boundary defined geometry aka outer form often defined via meshs. Let’s dive into some of the simple geometries and then looking at some more complex structures:
Implicit geometries are geometries defined via f(x,y,z) = 0 defining their surface, the boundary between inside and outside and they are ideal to define repetitive or periodic 3D infill geometries.
Sphere: x2 + y2 + z2 – r2 = 0
When you ever tried to compose a sphere as a mesh, you know there are many ways to do so, and all are more complex than this simple description, and as you realize, the formula is perfect, it’s not an approximation – this is the nature of implicit formula. When you try to visualize an implicit formula, then you need to discretize and there the approximation takes place, as a mesh or as voxels.
Another nifty property of the sphere, it is the minimal surface to circumvent a volume, and through this blog-post, the minimal surface will become a common theme.
Cube: max(abs(x),abs(y),abs(z)) – w/2 = 0
Plane: z = 0
As I render only -10 to 10 to each axis, it creates a small plate:
Let’s move to the world of minimal surfaces, so called Triply Periodic Minimal Surfaces (TPMS), those can be expressed in implicit form and have some properties as sought for infill geometries.
In differential geometry, a triply periodic minimal surface (TPMS) is a minimal surface in ℝ3 that is invariant under a rank-3 lattice of translations. These surfaces have the symmetries of a crystallographic group. Numerous examples are known with cubic, tetragonal, rhombohedral, and orthorhombic symmetries. Monoclinic and triclinic examples are certain to exist, but have proven hard to parametrise.
Wikipedia: Triply Periodic Minimal Surface (TPMS), retrieved 2023/02/08
One of the simplest yet powerful formula:
Schwarz P: cos(x) + cos(y) + cos(z) = 0
increasing the frequency or scale of the structure:
By extending the formula with +a, we can animate it:
Schwarz D: sin(x)*sin(y)*sin(z) + sin(x)*cos(y)*cos(z) +
cos(x)*sin(y)*cos(z) + cos(x)*cos(y)*sin(z) = 0
Neovius: 3*(cos(x)+cos(y)+cos(z)) + 4*cos(x)*cos(y)*cos(z) = 0
C(Y) Surface: sin(x)*sin(y)*sin(z) + sin(2x)*sin(y) + cos(x)*sin(2y) + sin(2y)*sin(z) + sin(2z)*sin(x) + cos(x)*cos(y)*cos(z) + sin(2x)*cos(z) + cos(x)*sin(2y) + cos(y)*sin(2z) = 0
Fischer Koch: (cos(x)*cos(y)*cos(z) + cos(z)*cos(x)) –
(cos(2x)+cos(2y)+cos(2z)) = 0
S Surface: cos(2x)*sin(y)*cos(z) + cos(2y)*sin(z)*cos(x) +
cos(2z)*sin(y)*cos(y) – 0.4 = 0
Gyroid: cos(x)*sin(y) + cos(y)*sin(z) + cos(z)*sin(x) = 0
FRD: 8 * a*cos(x)*cos(y)*cos(z) + b*(cos(2x)*cos(2y)*cos(2z)) –
c*cos(2x)*cos(2y) – d*cos(2y)*cos(2z) – e*cos(2z)*cos(2x)
Let’s explore this form more thoroughly, we animate a, b, c, d, and e and see what it does, essentially we animate -1 to 1 in sinus, 0 eliminates of the chunk of the formula:
Gyroid Skeletal: 10*cos(x)*sin(y)+cos(y)*sin(z)+cos(z)*sin(x)) –
0.5*(cos(2x)*cos(2y)+cos(2y)*cos(2z)+cos(2z)*cos(2x)) – 14
P Skeletal: 10*(cos(x)+cos(y)+cos(z) –
5.1*(cos(x)*cos(y)+cos(y)*cos(z)+cos(z)*cos(x)) – 14.6
By changing the last substraction of 14.6 to 10 or 8, the structure get more dense – ideal to use.
The P Skeletal connects 6 arms to each other.
IWP Skeletal connects 8 arms to each other.
Schwarz D Skeletal connects with 4 arms to each other.
The above “skeletal” minimal surfaces are ideal for lattice structures, likely most usable in context of voxel-based 3D printing approaches, such as SLA, SLS, SLM and so forth, but less ideal for traditional FDM where the lattice is sliced Z-planar again kind of defeating the overall purpose of lattice structures.
D Surface: cos(x)*cos(y)*cos(z) – sin(x)*sin(y)*sin(z)
As Juergen Meier created a variant, adding a, which gives these variants:
providing a structure using 4 arms to connect each other.
Slic3r and Prusa Slicer are providing gyroid infill pattern since early version, but beyond that it seems no to little development happened since (2022/12).
Let’s see how implicit geometry can be transformed into slices (FDM) or voxels/pixels (SLA, SLS etc)
Pros
Cons
Pros
Cons
Here some early G-code for FDM 3D printer using PyImplicit tool tracking the implicit surface as 2D contour:
The implicit surfaces only define the surface, either:
In order to create watertight meshs the volume needs to be limited with a boundary box, and Marching Cube is performed from outside to get proper mesh to post-process afterwards.
Now you may wonder, what’s the fuss with all those forms, why doing this complicate implicit form, why not just create a few forms as meshs right away and repeat them orderly – well, here it comes why:
Changing the frequency or scale s0 and s1 can be achieved by:
znorm = (z-zmin) / (zmax-zmin)
s = (1-znorm)*s0 + znorm*s1 or
s = lerp(s0, s1, znorm)
f = surface(x*s, y*s, z*s)
This shows the power of generative geometries, we simply can define the scale or frequency of a geometry at any point, given we transit within reason and not too sharply to cause discontinuty.
Alike changing thickness:
znorm = (z-zmin) / (zmax-zmin)
t = lerp(t0, t1, znorm)
f = abs(surface(x,y,z)) – t
What looks very complex is done quite simply with:
znorm = (z-zmin) / (zmax-zmin)
f = lerp(surface1(x,y,z) , surface2(x,y,z), znorm)
This is quite powerful property, to be able to morph from one implicit form to another with such a simple formula.
Contineous Transitions:
Discontinueous Transitions:
Algebraic addition has the effect of apply one geometry within another, alike recursion:
Algebraic multiplication has the effect of clipping, or geometrical intersection:
One can map the coordinates, and create a cylindrical gyroid, where former X & Y become distance and rotation angle, and Z remains as is, and so spherical projection is possible as well, or even feed coordinates through implicit formula itself:
Next blog-post(s) I will go into further details utilizing TPMS in Additive Manufacturing (AM) like FDM/FFF, SLA, MSLA, SLS, MJF or SLM – each one of them have unique features and limitation for using those Parametric Generative Infill Geometries.
In case you wondered of the different styled visualization through this blog-post, let me show you the different approaches to discretize implicit defined surfaces.
The code is rather simple with OpenSCAD yet rather slow: either skin is true or false, and delta determines the thickness of the skin if enable:
t = 1;
r = 20*t;
st = 1/2;
delta = 0.2;
function schwarz_p(x,y,z,s=1) = cos(x*s) + cos(y*s) + cos(z*s);
skin = true;
for(x=[-r:st:r])
for(y=[-r:st:r])
for(z=[-r:st:r]) {
f = schwarz_p(x,y,z,360/20/2);
if(skin && abs(f)<delta) // -- skin only
translate([x,y,z]) cube(st);
else if(!skin && f<delta) // -- inside/outside
translate([x,y,z]) cube(st);
}Rendered via voxelation:
Rendered in OpenSCAD via marching cube algorithm with Level Surfaces:
Following experiments were done with Spirula/Implicit3 within the browser, the implicit formulas are rendered in realtime at 100-500 fps using OpenGL’s GLSL (GL Shader Language):
One has to clip the formulas with a cube in order to have a limited set, otherwise you get a full screen looking at infinite X, Y & Z, here Schwarz P:
In order to create a mesh, I developed PyImplicit which utilizes Numpy library to calculate the implicit formula fast, and then run a Marching Cube algorithm over the result in order to get a discrete mesh like STL, OBJ, or 3MF to process further for 3D printing.
*) some of my larger prints I attach RFID tags, e.g. as on top of the variable frequency Schwarz P print, which I store the print UID from my Prynt3r job which logs all my prints with all settings and webcam snapshots. In future blog-post I will illustrate my NFC/RFID setup.
And Polyviuw is a small mesh viewer using Polyscope Python as backend to display it as mesh:
It is easy to create huge files when exporting an implicit generative infill geometry and one ends up with a 700MB binary STL file, which becomes hard to view at least on my system. To handle complex outer forms, with complex inner geometries I estimate reaching multiple gigabytes large files – let’s see.
Updates
machine_uuid detailsPrynt3r (prynt3r) is the Python reimplementation (2022) of my own Print3r (print3r) which was written in Perl back in ~2017.
After download and installation, you can start to configure and use it:
____ . __ _____ .
* / __ \_______* ______ / /|__ /_____ *
/ /_/ / ___/ / / / __ \/ __//_ </ ___/ . | *
. / ____/ / / /_/ / / / / /____/ / / -=*=- .
/_/ /_/ \__, /_/ /_/\__/____/_/ * . |
/____/ V0.0.8 * .
https://github.com/Spiritdude/Prynt3r
Prynt3r 0.0.8 USAGE: [<opts>] <cmd> <arg1> ...
commands:
slice <file1> ... slice file(s) into single gcode, e.g. use -o <fn> or --output=<fn>
print <file1> ... slice and send gcode to printer local or remote, e.g. define -d <dev> or --device=<dev>
preview <file1> ... slice file(s) into single gcode and launch gcode viewer
gconsole starts interactive g-code console
log [<s>] [#<n>] list log, query term <s> or list log entry '#<n>', with --output or -o you can list only particul
ars
client start client process, so remote prynt3r can access it
file-formats:
stl, obj, off, 3mf, ply, scad, jscad, zcad, vdb, svg
options:
--help print this message
--version print version and exit
--device=<dev> set device (default: /dev/ttyUSB0)
-d <dev>
--printer=<name> set printer name (default: default)
-p <name>
--slicer=<slicer> set slicer: cura, cura-legacy, cura4, cura5, curax, prusa, slic3r, slic3r-pe, slicer4rtn, cura-slicer, super, mandoline, 5dmaker, kirimoto, zplus, lab, vox3l, voxgl, metatron, enoch, goslice, (default: slic3r)
-s <slicer>
--gcode-viewer=<cmd> set gcode previewer (default: yagv)
--verbose=<n> increase verbosity
-vvv
--extended or -x extended output, e.g. for 'log' command
--quiet or -q stay quiet, only output warnings or errors
--output=<fn> slice: slicing into a particular file 'prynt3r slice cube.stl -o test.gcode' or
-o <fn> log: 'prynt3r log -o uid,files,args' to list particular fields of the log file
--placement=<loc> set location: 'none', 'center', 'random' (default: none)
--rotate=<x>,<y>,<z> rotate model(s)
--scale=<f> scale model(s) uniformly
--scale=<x>,<y>,<z> scale model(s), if value has 'mm' appended, then axis is set absolute
e.g. "0,0,20mm" scales model(s) to 20mm Z height, all axes with 0 scales
proportionally
--multiply-part=<n> multiply model(s)
--recenter=<s> recenter models (default: 1), recommended when rotating
--relevel=<s> relevel models (default: 1), recommended when rotating
--uid=<uid> set uid for print process (otherwise unique will be generated)
--keep keep all temporary files (for debugging)
--scad treat arguments as OpenSCAD code, e.g. --scad 'cube(20)'
--scadlib=<lib>[,<lib2>] consider libraries as well, e.g. --scadlib=parts.scad
--zcad treat arguments as OpenZCAD code
--jscad treat arguments as OpenJSCAD code
slicing options (slicer independent):
--machine-name=<v> set machine name (default: "Unknown")
--machine-uuid=<v> set machine uuid (default: "")
--machine-width=<v> set machine width (default: 200.0)
--machine-depth=<v> set machine depth (default: 200.0)
--machine-height=<v> set machine height (default: 180.0)
--nozzle-diameter=<v> set nozzle diameter (default: "0.4")
--line-width=<v> set line width (default: 0.4)
--layer-height=<v> set layer height (default: "0.3")
--filament-diameter=<v> set filament diameter (default: "1.75")
--fill-density=<v> set fill density (default: "20")
--temperature=<v> set temperature (default: "200")
--first-layer-temperature=<v> set first layer temperature (default: "210")
--bed-temperature=<v> set bed temperature (default: "45")
--first-layer-height=<v> set first layer height (default: "0.25")
--first-layer-speed=<v> set first layer speed (default: "20")
--skirts=<v> set skirts (default: "2")
--brims=<v> set brims (default: "0")
--rafts=<v> set rafts (default: "0")
--support=<v> set support (default: "none")
--support-angle=<v> set support angle (default: "60")
--seam=<v> set seam (default: "aligned")
--top-thickness=<v> set top thickness (default: "0")
--bottom-thickness=<v> set bottom thickness (default: "0")
--wall-thickness=<v> set wall thickness (default: "0")
--perimeters=<v> set perimeters (default: "2")
--top-layers=<v> set top layers (default: "2")
--bottom-layers=<v> set bottom layers (default: "2")
--start-gcode=<v> set start gcode (default: "G28 X0 Y0\\nG1 X100 F6000\\nG28 Z0\\nM206 X0 Y-25 Z0.15\\n\n")
--end-gcode=<v> set end gcode (default: "G1 Y290 F6000\\nM104 S0\\nM140 S0\\nM84\\n")
--abort-gcode=<v> set abort gcode (default: "M104 S0 ; extruder heater off\\nM140 S0 ; heated bed heater off (if you have it)\\nG1 X10 F9000 ; go way to the left\\nM84 ; motors off\\n")
--prepend-gcode=<v> set prepend gcode (default: "")
--retraction-length=<v> set retraction length (default: "2")
--retraction-speed=<v> set retraction speed (default: "70")
--print-speed=<v> set print speed (default: "60")
--travel-speed=<v> set travel speed (default: "130")
--perimeter-speed=<v> set perimeter speed (default: "60")
--small-perimeter-speed=<v> set small perimeter speed (default: "15")
--infill-speed=<v> set infill speed (default: "80")
--bridge-speed=<v> set bridge speed (default: "60")
--extruders-count=<v> set extruders count (default: "1")
--cool-fan-speed=<v> set cool fan speed (default: "100")
--cool-fan-speed-min=<v> set cool fan speed min (default: "30")
--cool-fan-speed-max=<v> set cool fan speed max (default: "100")
examples:
prynt3r print cube.stl
prynt3r print cube.scad
prynt3r -p prusa-i3 print --scad 'cube(20)'
prynt3r -p ashtar-k-1 -s cura5 slice cube.3mf
prynt3r -p ashtar-k-1 -s cura5 print structure.vdb -d tcp:192.168.1.32:0
prynt3r -s prusa slice cube.stl -o a.gcode
prynt3r preview cube.stl
prynt3r log
prynt3r log cube.stl -v
prynt3r log '#100' -xv
prynt3r log -o uid,args,files
prynt3r -d /dev/ttyACM0 client &
prynt3r -d /dev/ttyACM1 gconsole
> M115First you need to adjust the profile for your 3D printer(s):
% cd ~/.config/prynt3r/printer
% cp /usr/share/prynt3r/printer/default.ini myprinter.inias next edit myprinter.ini according the specifications of your printer, after that your profile is available as -p myprinter or --printer=myprinter when calling prynt3r:
% prynt3r -p myprinter print --scad 'cube(20)' --fill-density=0Optionally, if you run a bunch of 3D printers, define machine_uuid in your .ini file, which references the Marlin’s UUID or RepRapFirmware’s Board ID or as fallback the MAC of the Wi-Fi – this is what the machine_uuid is verified with on serial or remote connection.
Retrieve the UUID with
% prynt3r -d /dev/ttyACM0 gconsoleand then send M115 and M122, like:
Marlin M115
% FIRMWARE_NAME:Marlin 2.0.9.1 (Sep 23 2022 16:48:31) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ashtar K E3 #3 L8 EXTRUDER_COUNT:3 UUID:8309209b-1c20-11ed-861d-0122ac4e0002
Cap:SERIAL_XON_XOFF:0
Cap:BINARY_FILE_TRANSFER:0
Cap:EEPROM:1
Cap:VOLUMETRIC:1
Cap:AUTOREPORT_POS:0
Cap:AUTOREPORT_TEMP:1
Cap:PROGRESS:0
Cap:PRINT_JOB:1
Cap:AUTOLEVEL:0
Cap:RUNOUT:0
....RepRapFirmware M122
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0alpha (2021-07-09 08:59:45) running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: ABR3A-KA67A-J03J0-40TFS-21D0Z-RTDXU
Used output buffers: 1 of 40 (2 max)
=== RTOS ===
Static ram: 102768
Dynamic ram: 105632 of which 0 recycled
Never used RAM 35304, free system stack 155 words
Tasks: NETWORK(ready,25.8%,546) ETHERNET(notifyWait,0.0%,662) HEAT(notifyWait,0.0%,361) Move(notifyWait,0.1%,302) CanReceiv(notifyWait,0.0%,939) CanSender(notifyWait,0.0%,371) CanClock(delaying,0.0%,340) TMC(notifyWait,1.1%,112) MAIN(running,72.1%,438) IDLE(ready,0.1%,29) AIN(delaying,0.8%,262), total 100.0%
Owned mutexes: USB(MAIN)
...without Board ID, checking the WiFi MAC:
- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
Bad header: 0/0
WiFi firmware version 1.26-08S32-D
WiFi MAC address ad:15:a3:15:6c:95
WiFi Vcc 0.00, reset reason Power up
WiFi flash size 0, free heap 151828A printer is identified with:
--printer=<nick> or -p <nick><nick>.ini: machine_name=“Full Name” where you write it out exactly, e.g. “Ashtar K #3 PAX”, which means it’s Ashtar K number 3 with PAX extension<nick>.ini: machine_uuid=<uid> where you ensure the actual identity with the hardware at time of connectingYou can print to a computer which has 3D printers connected to, if you run
prynt3r -d /dev/ttyACM0 client &
prynt3r -d /dev/ttyACM1 client &on the host which has the printer(s) attached, and then on your main computer:
prynt3r -d tcp:host:0 -p myprinter1 print --scad 'cube(20)'
prynt3r -d tcp:host:1 -p myprinter2 print --scad 'cube(20)'[Coming Soon] If you run RepRapFirmware like on Duet3D boards, then you can reference them as such:
% prynt3r -d rrf:192.168.0.100 -p myprinter1 print --scad 'cube(20)'it will upload the .gcode and run it, yet, prynt3r will wait until the print is finished.
So far the slicer independent settings of Print3r are the same as for Prynt3r, so you can migrate the ~./config/print3r/printer/* into ~/.config/prynt3r/printer/* simply, the same with the macros.
cd ~
mkdir .config/prynt3r
cp -rp .config/print3r/* .config/prynt3r/The same as print3r:
The differences as print3r:
trimesh doing import/export/manipulation of meshs incl. diverse mesh formatsUpdates:
Formnext 2022 was a 4 days Additive Manufacturing (AM) event in Frankfurt (Germany) November 15-18 2022, and it had ~750 exhibitors, two huge halls numbered 11 and 12 each with two floors. I attended the 4 days and it was pretty overwhelming. I try to give an overview, for myself to process what I saw, and perhaps for you who couldn’t attend.
E3D is an old timer among 3D printing enthusiasts, so I start with their booth:
I was surprised to get to know E3D manufactures for UltiMaker their CC printcore.
Duet3D is a small UK-based company, but very influential due their excellent and often praised customer support and support forum aside of their slowly expanding board selection:
I met Tony Lock, and we discussed current state of multi-axis support in Duet/RepRapFirmware, and he showed me the Open5X by Freddie Hong printing non-planar as crafted by FullControl.xyz
I briefly pitched my new tool VirtualGcodeController (vgcodectl) which sits between printing program and the device, and able to change G-code on the fly, transparently bi-directional – as I was told Duet has an alike infrastructure called Duet Software Framework (DSF) which I wasn’t aware of.
Also check this brief interview by Mihai Design:
At german-based Multec booth I saw a multi-printhead setup with a rotating seal to prevent the inactive printheads leak filament – and a precise mechanism to lift the inactive printheads (patented):
Dutch-based company providing infrastructure to mix and extrude your own filament, not just for mixing different colors, but also different materials and achieve custom material properties – the only downside is the price-tag of those desktop filament extruders starting at 10K EUR – which is too high for its functionality for prosumers, and seems to aim for R&D departments of larger companies.
As I have been entering slicing development more seriously, and closely paid attention to possible competitors or collaborators – and interestingly, the majority responded positively when I approached them:
A small danish company, who recently patented interlocking (Z-offsetted layers) printing patterns.
I had a brief chat with Folmer Gringer Brem about industrial slicer capabilities and customer needs, and what I have researched the past year.
A new french company is providing non-planar 5-axis slicer with a nice GUI, and were open enough to give an actual demo and I was impressed by the responsiveness of the GUI but were tight-lipped to reveal anything about the internals – 5-axis slicer with infill patterns:
A small 2 person german company, a spin-off from the university Bochum, also coding 5-axis non-planar slicer, showing a small desktop 6-axis robot to print an overhang model, their own logo, and it has infill – which means, they actually did properly slice 5-axis G-code. They were reluctant to go into the details, as their IP represent their core asset as a company:
AiBuild has a huge booth, lots of advertising, has been very secretive last year as they didn’t want to demo their software without NDA to anyone – but while attending Formnext 2022 I was able to get to talk to people who purchased the software, and all of them have been giving me strange feedback: a sort of underwhelming sensation – the software is costly and not deliver what is advertised: you need to know a lot of slicing in order to use the software – there is nothing “Ai” (Artificial Intelligence) as the company name implies, at least not with their slicing software.
On their booth they had the usual non-planar printed pieces, but none of them had infill, so they all are printed in vase-mode or single wall.
One feature I saw though impressed me, it was the live quality control they implemented, having a nozzle camera and machine learning / AI to determine over- and under-extrusion – something which I would say one should have under control, but perhaps it was to illustrate the detection mechanism.
Poland-based 5-axis printer manufacturer has progressed in hardware and software, and developed their own 5-axis slicer – the simulation shown as the actual printer prints – overall well designed.
I had a brief chat with Adam Wajda about the state of their hardware/software stack, very open and friendly exchange.
Hungary-based startup with a dual delta setup printing upside and downside at the same time. They were present last year Formnext 2021 already but with an inactive printer, and this time showing the printer in action:
Beside reducing print-time the printer also is able to print pieces which otherwise are hard or impossible print when layer orientation is given and surface quality is of high priority.
The newly merge Ultimaker + MakerBot = UltiMaker had no booth again, hardly any presence – the marketing / sales department seems in hybernation to skip such as event without their own booth, no hardware innovation on display, perhaps there is nothing (new) to show.
I visited the 3dimensional booth and someone showed me how to print “metal” (just steel as it turned out) with BASF metal filament on a Ultimaker S5, and having everything needed in a nice box and then send off to wash & sinter.
Snapmaker announced a new machine called Snapmaker Artisan: single head operation, yet changeable heads: FDM head, CNC head, laser head – very sturdy desktop machine, using linear motors:
Bleeding edge high temperature resisting materials, and to show the applications they built a most precise FDM printer I have seen so far – Chiara Mascolo briefly showed me the machine and samples:
Massive SLA and SLS machines shown:
The Formlabs booth was well visited, and it was hard to take photos until the last day of the expo – so just a brief video of the Form 3+ printing below:
German-based startup printing with 7 different light curable materials at the same time, drop size / resolution at 60um with the NovoJet C-7 – quite impressive, with the ability to blend drops or let them cure side-by-side giving new possibilities of material gradients in 3D space:
They also provide a station for fluid testing & development, so you can engineer your own material to print with. Even though this was a small both it was for me from a technical point of view most innovative I have seen so far.
As I was looking at resin printheads, I was approaching Global Inkjet Systems (GIS) – a subdivision of Nanodimension:
A massive industrial resin jetting 3D printer, build-volume at 500 x 250 x 200 mm printing with wax as support material. It is a closed-loop system, it prints, cures and measures the actual layers and adjusts live for the next layer – achieving 100um precision, yet only for industrial application due the cost of 1M USD per machine.
They developed their own packing algorithm in order to achieve high density packing ratio.
Italian-based “Betron Genesi” 4000 x 1900 x 1300mm build volume along with high volume extrusion (~20mm nozzle, layer height ~4-5mm based on my own photos) having excellent extrusion precision, along their real time temperature control:
Additionally is is a hybrid able to run also CNC milling on the same machine for post-processing.
Visited Phaetus expecting to just meet sales people instead I ran into Maximilian Arnold, owner of DropEffect which designs hotends under his own brand but also for chinese-based Phaetus as R&D director. I showed him photos of my early prototype of a Multi-In Mixing Hotend supposed to be printed in Aluminium and he immediately commented on my design and gave me useful input – unexpected interesting and fruitful exchange.
A brief interview with Max conducted by MihaiDesigns:
This booth impressed by the samples they showed:
France-based company combining FDM and CNC together:
What you achieve with this is incredible precise plastic pieces at 20um precision, while maintaining 500 x 500 x 500mm respectively 1000 x 500 x 500mm build-volume. They are milling with a round drill bit – CNC toolpath is calculated by Autodesk’s Fusion 360 though.
Turkish-based company wire arc welding with 6-axis robot:
Massive ABB 6-axis robot FDM printing on a rotating 2-axis bed . . . with shiny cyan/pink/violet lights, a bit of an overkill with the lights, but the setup was impressive:
It has been overwhelming expo for me, 4 days in noisy halls, constant audible and visual stimuli grown tiresome for me as I was eager to absorb all; I can say I looked at every single booth, and decided within few seconds if something caught my attention, and I knew to lookout for things I did not know or a company I did not recognize – for new companies in the arena of Additive Manufacturing. It took me a single day to roam both floors of a single hall, so at least it takes 2 days to explore two halls of the expo – and if you happen to explore a booth for more than a few mins, you end up with 3-4 days attending easily.
So, the overall impression of mine has been:
Some impressions of Frankfurt (Germany) . . .
That’s it.
Status: early prototype, metal printed model, temperature testing, no extruding yet
Updates:
This blog-post will be updated as I progress.
I experimented with the Diamond Hotend in the past, but I was limited with the setup given – and adding another color or otherwise change the design seemed impossible, but it has changed now.
Metal 3D printing has been a niche and high priced application the past years, but in 2022 many 3D printing services support:
at relatively low price and all of the sudden designing a FDM mixing hotend, where multiple filaments are mixed together before exiting the nozzle – like with the Diamond Hotend – can be printed in metal, like with aluminium – so, I started to design a Parametric Mixing Hotend.
Pros:
Cons:
Challenges:
The filament channels:
Mounting options, plain mounting holes 3x 20mm, or plate with 3x 40mm holes:
and adding my Parametric Part Cooler:
Early prototype printed in cold white eSun PLA+ 0.25mm layer height (~1h 20m print time):
Adding nozzle, heat cartridge, heat thermistor, heatsink fan and pneumatic couplers PC4 M6:
and just testing my Parametric Part Cooler using 50×15 blower fan:
which very likely leads to have a some sort of thermal insulator aka silicon sock for lower part of the heat chamber and nozzle.
The first attempt to order with WeNext using SLM failed, they were not able to find a way to print it without support, which was surprising as powder-based metal printing1) – the removal of support was not guaranteed, so I canceled the order.
The 2nd attempt with PCBWay – disclosure: they approached me a couple of weeks later to sponsor metal printing process, which I agreed on – also using SLM AlSi10Mg at first looked good at first, but then they also needed to add supports once the production step came close, and then I followed up and approved the production. The order was submitted November 5, and 14 days later the piece was at my door.
Preassembled with MK8 0.4mm nozzle, 30mm fan, heat cartridge and thermistor:
and 2x PC4-M6 threaded, with PTFE tubes:
My test rig:
I heated to 50C°, 80C° and 100C°:
M303 for 100C° and keeping it at 100C° for 10mins
As the lowest fin heats up significantly, as a first remedy I lowered the heatsink fan a bit:
After the tests, I changed the design slightly:
Submitted to PCBWay 2022/11/29 for manufacturing review, a day later I was informed of thin walls of the pipes near the heatbreak (<1mm) and I gave OK to manufacture.
The thin heatbreak walls seemed to help:
Heatbreak is most critical, and has to be short and has to be a hard cut temperature gradient-wise – and 0.5mm wall thickness is still too much. So, regardless of cooling fan on the heatsink, if the heatbreak is too thick, too much heat creeps up or away – it’s not a matter of cooling capacity, but conductivity.
Updates:
The XCR3D 3in1 S1 aka Bigtree ZSYong 3in1 is a neat 3 in 1 out switching hotend (non-mixing):
Pros:
Cons:
Very similar, but with symmertric E3D V6 heatsink:
It seems to me, the this 3-in-1 hotend with hexagon heatsink, was cloned from NF THC-01 3in1, and likely engineered by a small company, and now brands like BigTreeTech, XCR3D and others purchase in bulk the hotend black/red anodized and their white brand stamp on the hotend.
What makes things truly confusing is that the hotends from China have terrible naming, e.g. “3in1” and “2in1” are used for switching and mixing hotends, which are quite different functionalities, and otherwise the name does not distinct designs.
I adapted the Parametric Part Cooler using 50×10 blower fan for the XCR3D 3in1 S1 as well:
As you can see on the illustration and photos, put the part cooler on the heatsink, and then 30mm heatsink fan on top. The part cooler itself requires 50x15mm blower fan.
It is a bit fiddly as there are no clear threads for the screws on the heatsink, so the first mounting is crucial to thread properly.
In Configuration.h one has to update the thermistor type:
#define TEMP_SENSOR_0 5 // changed from 1 to 5
...
#define PID_FUNCTIONAL_RANGE 25 // changed from 10 to 25recompile, upload/update firmware and then run via G-code console the autotune PID procedure:
M303and after 3-5 mins or so, when the autotune is done, save settings in EEPROM:
M500and one is done.
I really struggled to get decent quality prints first, as somehow the temperature reports were off by 40C°, and various Google searches gave the same wrong answers, the seller did not give proper detailed information about the thermistor either. Eventually at Amazon one customer gave the relevant information ATC Semitec 104GT-2/104NT-4-R025H42G and defining TEMP_SENSOR_0 5 in Marlin gave sane results.
Retraction settings are in my case 3mm at 70mm/s with apprx. 500mm long Bowden tube on my Ashtar C (CoreXY 400x400x380) and also Ashtar K #3 (300x300x360).
I really like the switching filament solution close to the hotend, compared to other multi-material solutions where materials are switched far away from the hotend; e.g. switching material is faster, but one has to still purge one material/color by 30-50mm filament – so I tend to use the multi-material/color feature for fast switching colors for single material/color prints.
Following procedure I use when switching material:
T1“)T0“so by default “T0” is ready to be printed. In order the print with the other materials, I have two macros with Print3r e3-t1 and e3-t2.
print3r --printer=ashtar-c-1 print cube.stl @e3-t1
print3r --printer=ashtar-c-1 print cube.stl @e3-t2~/.config/print3r/macro/e3-t1:
prepend_gcode="G91\nT0\nG1 E20 F100\nG1 E-55 F3000\nT1\nG1 E55 F3000\nG1 E30 F100\nG90\nG92 E0\n"
end_gcode="G1 Y{$machine_depth-10} F6000\nG92 E0\nG91\nG1 E-2 F2000\nM140 S0\nM104 S0\nG1 E-55 F3000\nT0\nG1 E55 F3000\nM84\nG90\n"and ~/.config/print3r/macro/e3-t2:
prepend_gcode="G91\nT0\nG1 E20 F100\nG1 E-55 F3000\nT2\nG1 E55 F3000\nG1 E30 F100\nG90\nG92 E0\n"
end_gcode="G1 Y{$machine_depth-10} F6000\nG92 E0\nG91\nG1 E-2 F2000\nM140 S0\nM104 S0\nG1 E-55 F3000\nT0\nG1 E55 F3000\nM84\nG90\n"The way it is composed: start_gcode + prepend_gcode + slicing G-code + end_gcode.
As it happened to me several times, the hotend clogs up and the reason is often the filament is not hot enough, and when pulling back/retracting it forms a long pointy drag, and might break and the next cold filament jams in further down, but not enough to melt – it clogs up eventually.
First solution is to heat hotend at 240C° at least, not more than 250C° because of the PTFE – and try to push with filament on top, eventually some of the clogging might melt and free the nozzle.
Second solution is removing the lower part with heatbreak, heatblock, by opening the worm screws at the heatsink, and review the PTFE intake:
Status: experimental, not yet released
Updates:
As I was developing the 5-axis PAX printhead, and implement Inverse Kinematic (IK) for it in RepRapFirmware (RRF) for Duet3 board, the development speed was slow due the overhead to get to know the RRF written in C++, hence very verbose code, and the “recompiling, uploading, and reboot of the board” cycle to iterate the development – which turned out to be very slow and tedious.
My first remedy was to do a pre- or post-processor which takes tool coordinates and converts into motor positions applying IK, and Print3r supports it via declaring a post-processor like --post_something=something %i %o and then use with --post=something, but would only be a Print3r-centric solution.
So I thought, why not do a virtual serial device, and have a framework where the controller behaves like a physical one, but is pure software and thereby shorten development cycle to convert G-code coming out of a slicer or some software and then being processed and then sent to the 3D printer or robot – so the Virtual G-code Controller (vgcodectl) was born.
It’s main feature is that it operates bidirectional:
in essence it operates as in bidirectional intermediary looking like a serial port and thereby can be integrated into existing G-code-based machine park.
slicer/console/controller ⇆ physical device
↓
slicer/console/controller ⇆ vgcodectl ⇆ physical device
as a result the setup looks like a capability extended device:
% vgcodectl -h
VirtualGcodeController 0.1.4 USAGE: [<opts>]
options:
--help or -h this help
--version display version & exit
--verbose=<n> increase verbosity
-v or -vvv
--quiet or -q don't output to device or console anything unless an error
--output=<device/file> set output, e.g. /dev/ttyUSB0 or file or another device (default: /dev/stdout)
-o <device/file>
--controller=<ctl> set controller (default: conf['output'])
-c <ctl>
--keep-orig or -O enable to keep original g-code line as comment (default: off)
--keep-comment or -C enable to keep original comment (default: off)
hint: --keep-orig/-O includes comment as well
--serial-speed=<s> set serial speed [baudrate] (default: 115200)
--serial-timeout=<s> set serial timeout [s] (default: 0.1)
--check-code-timeout=<s> set code checking timeout [s] (default: 1)
--output-value-format=<fmt> set output value format (default: .4f)
examples:
vgcodectl --output=/dev/ttyUSB0 &
cat test01.gcode > pass0.pty
print3r --device=pass0.pty print tests/test01.gcode
print3r --device=pass0.pty print --scad 'cube(20)'
vgcodectl -o /dev/ttyACM0 -c gcode+ -Ov
Let’s try pass2 controller, which doubles X, Y and Z coordinates.
As first we start the controller:
% vgcodectl -c pass2 -O
== VirtualGcodeController 0.0.3 == https://github.com/Spiritdude/VirtualGcodeController
; VirtualGcodeController 0.0.3, created 2022-10-28T13:23:23.513285
; verbose = 0
; output = "/dev/stdout
; serial_speed = 115200
; controller = "pass2"In another terminal we take a sample G-code and send it into pass20.pty serial port (“pass2” plus the “0” indicates the first instance of pass2 controller):
% cat tests/test01.gcode > pass20.ptyand the vgcodectl outputs to stdout as it is the default:
G28 X0 Y0 ; G28 X Y
G92 ; G92 ; reset
G90 ; G90 ; abs coords
G0 X200 Y200 ; G0 X100 Y100
G1 X200 Y220 E1.2000 ; G1 X100 Y110 E1
M84 ; M84
As you notice, the new G-code is altered, e.g. X, Y and Z is doubled, the E is multiplied by 1.2 in this case, and the original G-code is appended as comment due the -O switch used (--keep_orig or -O).
If we did call vgcodectl with --output=/dev/ttyACM0 the end point would be a real 3D printer for example at /dev/ttyACM0.
% print3r --printer=ashtar-k-3 --device=pass20.pty print tests/test01.gcode
== Print3r 0.3.18 == https://github.com/Spiritdude/Print3r
print3r: conf: device pass20.pty, Ashtar K #3 E3 38x30x33, build/v 300x300x330mm, nozzle/d 0.4mm, layer/h 0.25mm, filament/d 1.75mm
print3r: authenticated "Ashtar K #3 E3 38x30x33" (8a09209a-1b93-11ed-861d-0242ac120002) at pass20.pty
print3r: print: 0h 00m elapsed, eta 0h 00m, 100.0% complete, z=0.00mm, layer #0, filament 0.00m as indicated, the pass20.pty operates bidirectional, reports back the proper UUID as requested by print3r and then sends G-code forward and does proper synchronous messaging back and forth.
print3r ⇆ pass2*.pty:vgcodectl ⇆ /dev/ttyACM0
Following controllers are available:
pass: it’s a simple pass-through changing no code, for debugging purposespass2: double X, Y and Z, and multiply E by 1.2
scale: scaling X, Y, Z and E, rather experimental / for debugging purposes--scale=<s> to set scale in , e.g. 0.8 (default: 1.0)gcode+: writing low-level G-code and replace E automatically based on distance
G0 X100 Y100 and then G1 Y110 E and the G1‘s extrusion will be calculated--layer-height=<lh> [mm] (default: 0.2)--line-width=<lw> [mm] (default: 0.4)--filament-diameter=<d> [mm] (default: 1.75)delta: implementing cartesian XYZ -> T1,T2,T2 motor angles, using Delta printer inverse kinematicspax: implementing 5-axis inverse kinematics for PAX printhead5axis: generalized 5-axis driver, define forward kinematics, automatic inverse kinematics calculated:
open5x: Open5xpax: PAX Printhead, same as pax controller, but defined within 5axis controllermacros: implementing RepRapFirmware’s M98 functionalityNote: vgcodectl is currently under heavy development, API subject to change a lot – check back this page frequently.
This covers vgtcodectl 0.1.6 API:
controllers/<controller> /:main.py
def _map(self,c=None) function, in there you can recalculate any existing G-code, the c contains a dictionary with all the G-code values, the function returns
{ "G": 0, "X": 100.0 } – note: order matters, make sure ‘G’ or ‘M’ key comes first for G or M commands"G0 X100.0" or G0 X100.0\nG1 X110 E1.2"[ "G0 X100.0", "G0 X110.0" ], each element is a line[ { "G": 0, "X": 100 }, { "G": 0, "X": 110 } ], each element is a lineNone is returned, no change of G-code is made and the original data is passed on"" (empty string) is returned, nothing is passed on (mute)def __init__(self,conf=None) function be composed, where persistent state can be stored, and referenced in _map() then; the conf is the configuration of vgcodectl:vgcodectl --test="ABC" ... becomes conf['test'] available within __init__(), the controller profile profile.json is loaded and available as conf['profile']conf as self.conf then _map() has access to it as well with self.conf['test'] or self.conf['profile']['name']profile.json (optional):
name (string): full name of the controllerversion (string): version of the controller, e.g. “0.1.0”e.g. controllers/mine/main.py:
def __init__(self,conf=None):
pass
def _map(self,c=None):
if 'X' in c:
c['X'] *= 2
return cthen the controller can be referenced as such:
% vgcodectl -c mine -v
== VirtualGcodeController 0.0.7 == https://github.com/Spiritdude/VirtualGcodeController
vgcodectl: 2022-10-31T06:48:14.026650: loading <mine> profile
vgcodectl: 2022-10-31T06:48:14.026705: loading <mine> code
vgcodectl: 2022-10-31T06:48:14.027444: created mine0.pty (/dev/ptmx,/dev/pts/7)
vgcodectl: 2022-10-31T06:48:14.027473: opening /dev/ptmx
; VirtualGcodeController 0.0.7, 2022-10-31T06:48:14.027622
; verbose = 1
; quiet = 0
; output = "/dev/stdout"
; keep_orig = 0
; keep_comment = 0
; serial_speed = 115200
; serial_timeout = 0.1
; check_code_timeout = 1
; output_value_format = ".4f"
; ignore_codes = ["M117"]
; controller = "mine"The scale controller is just an experiment, to scale G-code with a factor:
% vgcodectl -c scale --scale=0.8 -o /dev/ttyACM0 &
% print3r --printer=ashtar-k-3 print --scad 'cube(20)' --fill-density=0 --device=scale0.pty
-scale=.8, --scale=1, --scale=1.2 processed with scale controllerUpdates:
Beside Fused Deposition Material (FDM) / Fused Filament Fabrication (FFF) aka extruding hot filament, there are more methods to 3D print:
and I choose JLCPCB which provides all four of them, whereas SLM only stainless steel is available as of 2022 – other 3D printing services provide wide-range of metals as well.
I ordered Pulley 20T 6ID (GT2 20 teeth 6mm inner diameter) as created via OpenSCAD Customizer, a piece which requires high accuracy and is mechanical stressed when in use, in following materials:
after 3 weeks the pieces arrived:
The overall quality of all pieces are excellent, regardless of automatic warnings I received while requesting the 3D printing task.
MJF has a nice finish, slightly reflective, deep dark, slightly grainy surface, and the top of the pulley is uneven, otherwise very precise.
3201PA with SLS is a very good piece, dark gray matte, grainy surface, very precise.
9000R resin with SLA produced a very nice piece, best finish at the top (near perfection), milky white color (vs cold white or warm white), but as it turns out not very precise:
It is very surprising to see the SLA having the biggest imprecision of all the samples.
316L stainless steel with SLM produced a nice piece as well, the top of the pulley is good, some unevenness where the top goes over the gear:
overall it’s grainy surface – indicating powder-based additive procedure. Holding the piece in the hand feels heavy compared the other materials.
The SLA / resin piece looked most smooth but it had the biggest imprecisions with over 3% in height and diameter – very surprising to me, it should comparatively be as precise as SLS and MJF. I cannot determine if it’s from the JLCPCB resin printer, or inherent of SLA.
SLS and MJF with Nylon performed expectedly very good, very sturdy and precise.
SLM stainless steel surprisingly very precise, yet unsuitable in real life application due the heavy weight.
I will update this part as soon long term (1-2 years) usage experience is available:
Update:
M503 dump beside Ashtar K
These are just my notes for configuring Makerbase (MKS) Monster8 V1.0 for Ashtar K and Ashtar C:
Pros:
Cons:
As first putting in the jumpers on all the driver sockets, in my case I choose UART mode for each one of the 8 drivers:
As of 2022/08, it seems Arduino is no longer able to compile Marlin-2.x (various compile errors within Arduino), at least with this board and everybody moved on the PlatformIO, which really surprised me.
As of 2022/08 there is no Linux GUI for PlatformIO but only PlatformIO CLI, but it’s simple enough:
pip3 install platformioAs next download the firmware, Marlin 2.0.x source from github:
git clone https://github.com/makerbase-mks/MKS-Monster8/
By default the board is configured for Voron 2.4 CoreXY, with 3x Z motors and Z probing in the midst of the bed and other things, so I had to edit Marlin/Configuration.h:
#define MACHINE_UUID "..." (use online generator to generate one)#define CUSTOM_MACHINE_NAME "Ashtar K #x L8", given Lead 8×8 are used#define LINEAR_AXES 3#define EXTRUDERS 1 (or 2, 3 max)//#define PREVENT_COLD_EXTRUSION needed for calibration//define COREXY[XYZ]_DRIVER_TYPE and E[012]_DRIVER_TYPE#define DEFAULT_AXIS_STEPS_PER_UNIT aren’t that important, as one can define it with M92 and M500 saving to EEPROM//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN#define INVERT_[XYZ]_DIR true or false#define INVERT_E[012]_DIR true or false#define [XYZ]_HOME_DIR -1#define X_BED_SIZE 380#define Y_BED_SIZE 300#define Z_MAX_POS 330and Configuration_adv.h:
#define NUM_Z_STEPPER_DRIVERS 1 even when two Z-stepper motors are attached#define E0_AUTO_FAN_PIN PA1 and attach extruder fan (watch polarity) on FAN1/J12 connector once those changes are made, build the firmware:
cd marlin\ firmware/MKS_MONSTER_Marlin-2.0.x/Marlin-2.0.x/
platformio runAfter a short while (~1min) it should finish successfully (if not, edit files).
Use a SD card, e.g. 8GB with simple FAT filesytem, and copy .pio/build/mks_monster8_usb_flash_drive/firmware.bin and mks_monster8.bin on the SDcard.
Insert the SD card into the Monster8 board next to the USB connector, and turn off and on the board (power cycle) – wait 5-10 seconds so the new firmware is installed, then the display should show the Marlin splashscreen eventually, and the board becomes available as USB device, in my case as /dev/ttyACM0 on Linux Ubuntu 20.04 LTS.
BOOT 0 button in the center of the board briefly (~2 secs)Linux: install apt install dfu-util and then
% sudo dfu-util -a 0 -s 0x0800C000:leave -D .pio/build/mks_monster8_usb_flash_drive/mks_monster8.bin -d 0483:df11
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x0800c000, size = 178820
Download [=========================] 100% 178820 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
% Ashtar K with 300×300 bed, single extruder:
> M503
-----
echo: G21 ; Units in mm (mm)
echo: M149 C ; Units in Celsius
echo:; Filament settings: Disabled
echo: M200 S0 D1.75
echo:; Steps per unit:
echo: M92 X100.00 Y100.00 Z400.00 E95.00
echo:; Maximum feedrates (units/s):
echo: M203 X300.00 Y300.00 Z5.00 E25.00
echo:; Maximum Acceleration (units/s2):
echo: M201 X2500.00 Y2500.00 Z100.00 E5000.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P3000.00 R3000.00 T3000.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
echo:; Home offset:
echo: M206 X-35.00 Y-3.00 Z0.15
echo:; Material heatup parameters:
echo: M145 S0 H180.00 B70.00 F0
echo: M145 S1 H240.00 B110.00 F0
echo:; PID settings:
echo: M301 P22.20 I1.08 D114.00
echo:; LCD Contrast:
echo: M250 C255
echo:; Power-Loss Recovery:
echo: M413 S1
echo:; Stepper driver current:
echo: M906 X500 Y500 Z700
echo: M906 T0 E500
echo:; Driver stepping mode:
echo: M569 S1 X Y Z
echo: M569 S1 T0 E
ok
>Ashtar C with 400×400 bed, 3 extruders with single nozzle:
> M503
-----
echo: G21 ; Units in mm (mm)
echo: M149 C ; Units in Celsius
echo:; Filament settings: Disabled
echo: M200 T0 D1.75
echo: M200 T1 D1.75
echo: M200 T2 D1.75
echo: M200 S0
echo:; Steps per unit:
echo: M92 X100.00 Y100.00 Z3200.00 E102.00
echo:; Maximum feedrates (units/s):
echo: M203 X500.00 Y500.00 Z2.00 E120.00
echo:; Maximum Acceleration (units/s2):
echo: M201 X9000.00 Y9000.00 Z50.00 E10000.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P1500.00 R1500.00 T1500.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.20 E2.50
echo:; Home offset:
echo: M206 X0.00 Y-5.00 Z0.15
echo:; Material heatup parameters:
echo: M145 S0 H180.00 B70.00 F0
echo: M145 S1 H240.00 B110.00 F0
echo:; PID settings:
echo: M301 P22.20 I1.08 D114.00
echo:; LCD Contrast:
echo: M250 C255
echo:; Power-Loss Recovery:
echo: M413 S1
echo:; Stepper driver current:
echo: M906 X700 Y700 Z1000
echo: M906 T0 E700
echo: M906 T1 E700
echo: M906 T2 E700
echo:; Driver stepping mode:
echo: M569 S1 X Y Z
echo: M569 S1 T0 E
echo: M569 S1 T1 E
echo: M569 S1 T2 E
echo:; Tool-changing:
echo: Z2.00
ok
>Part cooler fan is plugged into FAN0/J11, and if you enabled extruder fan (temperature dependent), plug it in FAN1/J12.
The jumpers are needed next to the fan connectors to define the voltage, either Vin (left) which is 12V-24V depending on the power input of the board, or 12V (middle) or 5V (right).
With 8 stepper drivers one is able to run:
The boards differ in physical layout such as connectors, but the firmware is the same, incl. the pin for the hotend cooler fan (which switches on conditionally when hotend heats up).
As of 2022 (I intend to update this) following boards are suitable for my cases:
| MKS Monster8 V1.0/V2.0 & 12864 display | Mellow Fly Super8 V1.2 & 12864 display | Duet 3 Mini 5+ & Duet 3 Mini 2+ | Duet 3 MB 6HC & Duet 3 Expansion 3HC | |
| Price | 55 EUR | 80 EUR | 155 EUR (120+35) | 385 EUR (255+130) |
| Stepper Drivers | 8 | 8 | 7 (5+2) | 9 (6+3) |
| Stepper Connectors | 9 (dual Z) | 8 | 7 | 9 |
| Hotends | 3 | 4 | 5 (2+3) | 6 (3+3) |
| USB | YES (USB-C) | YES (USB-C) | YES (MicroUSB) | YES (MicroUSB) |
| WIFI | – / YES3) | YES | YES1) | YES1) |
| Ethernet | – | – | YES1) | YES1) |
| Firmware | Marlin 2.x | Marlin 2.x RepRapFirmware 3.4.x | RepRapFirmware | RepRapFirmware |
Alternatively, there are Duet 2 & 3 clones available on the market:
| Duet 2 WIFI Clone | Duet 2 WIFI Original | Duet 3 6HC FYSETC Clone with Duet 3 3HC | Duet 3 6HC Original with Duet 3 3HC | |
| Price | 30-50 EUR2) | 175-185 EUR1) | 225 EUR (150+75) | 385 EUR (255+130) |
| Stepper Drivers | 5 | 5 | 9 (6+3) | 9 (6+3) |
| Stepper Connectors | 6 | 6 | 9 | 9 |
| Hotends | 2 | 2 | 7 (4+3) | 6 (3+3) |
| USB | YES (MicroUSB) | YES (MicroUSB) | YES (MicroUSB) | YES (MicroUSB) |
| WIFI | YES | YES1) | – | YES1) |
| Ethernet | – | YES1) | YES | YES1) |
| Firmware | RepRapFirmware | RepRapFirmware | RepRapFirmware | RepRapFirmware |
As of 2022, RepRapFirmware has become quasi standard in professional level 3D printing; while a lot of people run Klipper & Marlin together I can’t see the point doing this*) but rather have a more capable microcontroller like the Duet boards have to run the printer and manage WIFI / Ethernet at the same time. The only reason to run Klipper on a Single Board Computer (SBC) setup like Raspberry Pi is cost and enhance simple microcontrollers functionality this way.
| Marlin | Klipper & Marlin | RepRapFirmware with Duet | |
| CPUs | 1x Simple Microntroller | 1x SBC + 1x Simple Microcontroller | 1x Capable Microcontroller |
| Connectivity | USB only | USB, Ethernet and/or WIFI | USB and Ethernet or WIFI |
| Configuration | 3x .h files, recompiling required | single .cfg file | single .g file**) |
| Boot Time | 3s | Klipper 30s, Marlin 3s | 3s |
*) running different kinematics on the SBC converting G-code on the fly might be a reason
**) multiple .g file can be used optionally
If you are cheap, buy the Duet clones, if you want to support Open Source and Open Hardware community, buy from Duet3d.com direct, pricing is +45% of the clone prices, whereas the Duet resellers add another +15% (Clone: EUR 150, Duet3d.com: 220 EUR, Reseller 255 EUR)
RepRapFirmware: Mind the SD Card
Whether to run an original Duet board or a clone, one thing though one might pay attention to is the SD card, it is the weakest link as far I can tell:
After power-cycling the board, as it was in a strange state no longer responding to G-code properly, the display remained blank, no response to G0/G1 – after investigation it turned out, a single file vanished from the SD card: config.g – the main configuration file, and that is bizarre. The board appeared to be broken, when in truth, the SD card came to its end of life of operating reliably already after only ~1.5 years. The SD card was the one originally shipped with. In this light, a Marlin-based board requiring no SD card being present operates more reliable, unless one uses an industrial grade SD card.