like with Set Theory or more known when using Venn diagrams.
Brian Spilsbury started to look at 3D meshes for his JSxCAD library and how to process them: much closer to actual use cases of composing solids together and incorporate physical reality that two solids cannot occupy the same space at the same time while still unite or combine their shapes somehow.
He came up with the concept disjointed assembly of solids, which has the advantage of preserving the solids integrity in order to maintain individual information of material or colors per solid, and only change their shapes to align seamless to each other.
Disjointed Assembly or Exclusivity
The disjointed assembly or exclusive series of a, b and c like
a = sphere().color(red)
b = cube(1.5).color(green).translate([0.5,0.5,0.5])
c = cube(1).color(blue).translate([0.5,0,0])
may be written as
exclusive(a,b,c) = [ difference(a,b,c), difference(b,c), c ]
The parts no longer intersect any space of each other, and seamlessly can be fused now together. The order of such exclusivity matters now: the first solid in line is changed by all succeeding solids, and each next solid in the disjointed assembly the same, whereas the last solid remains untouched, hence, exclusivity with ascending order, the last dominates most.
Alternatively, exclusivity with descending order:
exclusive(a,b,c) = [ a, difference(b,a), difference(c,b,a) ]
and then a remains untouched, and all succeeding parts are dominated by the preceding ones.
While union(), difference() and intersection() are base functions handling solids, exclusive() introduces a lightweight approach to handle grouping of multi-material CSG solids by having the parts accessible individually afterwards.
OpenJSCAD: not yet, you can easily write a function to handle an array of solids, and creates difference() operations to each other.
JSxCAD:assembly() with ascending order implied, means, the last object is most dominant.
Unreleased/Unnamed CAD (which I currently work on 2019/04): exclusive() available, with optional last argument options with order: either "asc" (default) or "desc" like:
The workstation from which I print from (design and slice) is also connected via Ethernet. The printed violet PLA case I published a while ago on Thingiverse: Orange Pi Zero Case.
Preparation
On printhub (Orange Pi Zero) starting all the network clients processes:
The CTC I3 Pro B Y3228 low cost printer still runs Marlin 1.0 and 250,000 baudrate which won’t work with ser2net which print3r uses internally to print in network environment, so it needs to be flashed first with newer firmware, so it can be networked as well with common baudrate like 230,400. I upgraded the ~1 year old “CTC DIY I3 Pro B” 3d printer to Marlin 1.1.8 finally, first burning a bootloader with an Arduino Uno, and then properly configured Marlin, and now runs with 115,000 baudrate as well, so it can be networked as well.
Otherwise I stopped using Cura GUI or Slic3r GUI completely, and solely use print3r to first preview the Gcode, sliced with CuraEngine or Slic3r, and then print the parts, and because it runs on the command line, all the previous calls in the terminal are stored as history therefore I can scroll back (cursor-up/down) and repeat a job with slightly changed settings by editing the command line – something which GUI doesn’t offer, unless you save a printjob as .3mf and reload it and click around and change settings and save again as .3mf etc.
Command Inline OpenSCAD
Further, I often code OpenSCAD code directly with print3r for simple parts, e.g. caps for M6 threaded rods, something like:
Back in September 2018 I started to code the first parts for Ashtar C, a “Core XY” type 3d printer – finally, after several weeks waiting for the several parts (bearings, closed loop belts), I was able to finalize the bed and Z axis (2018/01/30) and perform the first test prints of Ashtar C #1 composed with 500mm 2020 T-slot and V-slot alu extrusions:
Specifications
CoreXY style
Build Volume: 380 x 400 x 380mm
Frame Size: ~500 x 500 x 500mm
Bed
400 x 400mm black bed sticker (~0.7mm thick)
400 x 400 x 4mm mirror (custom order)
4x bed corner mounts (printed), with M3 x 30 and spring and 4x washers each
420 x 420 x 4mm OSB
residing on 2020 T-slot alu extrusions.
Z Axis
1524mm GT2 closed belt: even though driving 4 threaded rods worked somehow, but not reliably therefore:
Option A
2x Nema17 (45Nm) stepper motor with 18 teeth GT2 pulley 5mm bore
2x 760mm closed belt
Option B
Using 3 or higher : 1 gear box (e.g. 3:1 gearbox could be used, but external shaft isn’t strong enough stabilized versus tilt) or alike to increase torque and still drive 4 threaded rods
4x M6 x 490mm threaded rods
4x M6 nuts with bed mounts (printed)
4x bottom Z rod mount (printed)
8x 606ZZ bearings (each rod has 2 bearings)
4x 18 teeth GT2 pulley 6mm bore
Challenges
Following challenges came up in the first test prints:
CoreXY principle works well, yet, the friction of each idler really matters as it increases risk of missing steps, well greased and well positioning mandatory
X endstop: right now positioned on the left hand side of the X beam, but the cable hangs down – likely need to reposition X endstop on the X carriage itself
the Bowden tube is long and so hangs to the bed, the tube (4mm OD, 2mm ID) isn’t stiff enough to bend upward, so requires some guidance to ensure it doesn’t ride on the bed surface and entangles with print process
E3D V6 clone this time really does not perform well: extrusion is not even, and missing steps of the extruder; requires further investigation.
thermistor seems off, increasing to “220C” print temperature, gave better and cleaner prints
After some delay of parts, I finally was able to finalize the belt routing and configure the firmware for Ashtar C #1:
Belt Routing
CoreXY belt routing of Ashtar C
Early on I decided to separate belts of motors A and B in the Z axis, so they would not cross as such, and also hoped one axis of the carriage holding the X beam would allow some idlers to redirect the belts – to save space and keep frame dimension and build (or printable space) dimension close.
The Bowden tube and the wires of the hotend are preliminary arranged:
Firmware
To configure the Marlin firmware turned out not that simple, as CoreXY has its own interdependencies of A & B motors: first X axis was reversed, whereas Y axis worked correctly, the INVERT_X_DIR setting on Configuration.h of Marlin did not help, it reversed the stepper motor direction, but not the actual X axis direction. After many attempts to use COREYX instead of COREXY I ended up
swap cables of A & B stepper motors
keep #define COREXY
#define INVERT_X_DIR = true and #define INVERT_Y_DIR = true
and X and Y direction worked correctly.
Preflight (no extrusion, just X & Y axis movement testing):
The stepper drivers still need some tuning, as I saw or rather heard a few missed steps at fast movement.
X & Y Endstops
The preliminary positions of the endstop are:
X endstop resides on the X beam left-hand side (USE_XMIN_PLUG)
Y endstop resides on the right-hand backside, (USE_YMAX_PLUG and HOME_DIR_Y 1)
X endstop
Y endstop
Z Axis
I postponed the actual details of the Z axis, as my main concern of the design was to have a good CoreXY setup and then see how I would achieve the Z axis.
In order to use 625ZZ bearings I started to use them as idlers directly (after cleaning the grease off their surfaces) and also use them to increase contact surface when driving a closed belt which drives 3 or 4 threaded rods M6 x 500mm:
Since the surface of the threaded rods is rough, I realized I need dedicated bearings to hold the rods at the bottom, otherwise the friction would wear on the mounts and increase its diameter. So, the Z axis isn’t finalized yet, but close.
A few OpenSCAD sketches I’m currently work on, and later will publish as well:
Simple Compact Extruder
I used some aluminium MK8-based extruders but realized I required my own parametric extruder using 625ZZ bearing and I looked around and found “Compact Bowden Extruder“ and adapted the overall design but coded it from scratch again:
It’s “right handed” by default, but filament can go both directions. The handle is pushed from “inward” with a spring, not so elegant, yet it saves space and filament does not have to go through the handle this way, which I prefer.
simple_compact_extruder() takes following parameters:
type:
"base": the base attached to the Nema 17 stepper motor
"handle": the push handle with the spring
"indicator": small indicate to put on the axis of the stepper motor
mount:
"none": (default) just attaches to Nema 17 stepper motor
"mount": simple mount (center)
"2020": extends flat (lower left version)
btd: Bowden tube diameter (default: 0mm), if 4mm is used, then Bowden tube can be inserted on both sides as guides for flexible filament close to the hobbed gear as shown below.
I use PC4-M6 push fit connector with PTFE tube 4mm OD / 2mm ID as guides, and began to use it right away on 3x printers for first tests:
Assembled Simple Extruder (M5 inset)
Assembled Simple Extruder (M5 inset)
Later I likely will integrate this design, once proven reliably working, with a Direct Drive Extruder design as well.
This design has been not yet printed but not yet in use, but soon as alternative to Chimera (dual hotends) or Cyclops (dual to one / mixing) hotends – two main issues:
part cooler needs to be narrow enough to sit aside of each other
part cooler should extend too much Y-wise too much, as the routing belt of the Ashtar C come into the way
The “Dual E3D V6 mount” was derived from preview designs as used for the Ashtar K:
Static Hotend Mount (Y Offset: 35mm, Z Offset: 20mm)
Simple Parametric Hotend Mount (Y-Offset: 0,20)
The first one used two pairs of M3 screws, whereas the other more simple one requires in its base version just one pairs of M3 to mount the E3D V6 hotend and the mount itself to the X carriage; in case a slight Y offset is used, two pairs of M3 are required again.
I will update this post once the designs are published, after thorough testing in real life.
2018/12/05: added MKS Gen L as alternative, for Ashtar C #1
2018/11/25: added RAMPS 1.4 as alternative, for Ashtar K #2
2018/08/28: initial version with CTC DIY I3 Kit
Sourcing Parts
The past months (2018/08) I began to use Aliexpress for ordering electronics – even prior going into 3d printing – and the past weeks my development cycles pretty much were depending on the 20-25 days delay until items arrived from China to Switzerland – and one develops some skill to anticipate what one would require as next – but some things only become known once you really tested parts thoroughly.
Anyway, the CTC DIY I3 Pro B (Geeetech DIY I3 Pro B clone) was still sold via Ebay (2018/08), at a price as low as EUR 80 incl. shipment, which is a true bargain.
Aliexpress (2018/08):
MKS Gen L mainboard (incl. drivers) with LCD (with dialer), 200×200 heatbed, end stops, cables: EUR 50
PSU 12V 240W: EUR 20
5x Nema 17 45Nm stepper motors: EUR 35
Total: EUR 105 (without endstops and various cables to connect all together)
CTC DIY I3 Pro B Kit (2018/08):
Anet 1.0 mainboard, with 2 Lines LCD (4 buttons), 200×200 heatbed, end stop, cables, PSU 12V 240W, 5x Nema 17 45Nm stepper motors
Total EUR 80 (all cables included)
So I decided to get another CTC DIY to source the parts in one go, and likely upgrade later with individually sourced parts to have dual extruder motors (two color or material printing).
In 2018/11, when I started to build a second Ashtar K 38x30x33 #2 I checked Ebay with following prices:
Ebay (2018/11):
MKS Gen L: EUR 28
MKS Gen L mainboard: EUR 16
5x A4988 drivers: EUR 6
RepRap Full Graphic LCD: EUR 11
RAMPS 1.4 with Arduino Mega, 5x A4988 drivers, Full Graphic LCD: EUR 28
5x Nema 17 40-50Nm stepper motors with cables: EUR 26-35
PSU 12V 240W: EUR 20
Total EUR 74 – 83 (missing: endstops and various cables to connect all)
Burning Bootloader on Anet 1.0 Board
For now I use an “Anet V1.0” controller board (Atmel 1284P), as part of a “CTC DIY Kit” as mentioned, and it required some preparation:
using Arduino Uno R3 (clone) and upload “Arduino ISP”
attach Anet V1.0 board (detach all other cables) to Uno R3
run “Burning Bootloader” with “Arduino as ISP” as writer
downloading Marlin and edit main Configuration.h (not yet published) to match my specifications
upload new firmware Marlin to “Anet V1.0” via USB upload
RAMPS 1.4 with RepRap Discount Full Graphic LCD
For the 2nd Ashtar K 3D Printer I used (2018/11) RAMPS 1.4 combo with Arduino Mega, which was easy to upload new firmware. RAMPS 1.4 is Open Hardware, the entire schematic and pinout is available or download diagram with pinout as one image (same as on the side) – but it’s also a hassle to plug correctly as the board plug descriptions are tiny or covered by parts so one has to consult documentation in details, and there many ways to do wrong (reverse or misalign plugs) and most of these can and do damage either the RAMPS 1.4 shield and/or the Arduino Mega beneath, including misaligning the endstops.
Endstops
using C and NC on the endstop and the board (power connector on the left) above the 2x Z motor connectors: XMIN, XMAX, YMIN, XMAX, ZMIN, XMAX, each:
top (Signal) -> C
middle (Ground) -> NC
bottom (5V) -> empty
while waiting for proper endstops to arrive, I salvaged microswitches from a faulty computer mouse to work as endstops
commented out #define MENU_HOLLOW_FRAME so selected item is inversed
pin_RAMPS.h:
see #if ENABLED(REPRAP_DISCOUNT_SMART_CONTROLLER) and the following #if ENABLED(CR10_STOCKDISPLAY)after the #else check BTN_EN1 and BTN_EN2 and reverse the pins (31 <-> 33) so clockwise dialing goes down (and not up).
MKS Gen L
Configuration.h:
#define MOTHERBOARD BOARD_MKS_GEN_L
As far I can tell the end-stops take DuPont females and pin order is the same as with RAMPS 1.4, but orientation is crucial – otherwise the GND and VCC is shorted.
Since 0.1.0 also arbitrary baudrate like 250000 (default of Marlin) is supported (Linux only, other platforms not yet), aside the common 115200.
Preview
As external Gcode viewer for preview command yagv is used, a very basic viewer – at a later time it might be replaced.
% print3r preview cube.scad
which converts, slices and preview the Gcode.
Extensive Documentation
Since the functionality of print3r is growing steadily, the requirement for proper documenation demanded its own Print3r Wikiwhere you find up-to-date information.
Note: The information is outdated as print3r natively supports networked printing, see 3D Printing: Print3r 2.x: Networked Printing (2019/02/27), but this information is still useful bridging USB to TCP in general.
Introduction
The moment you deal with more than one single 3d printer, but multiples – you want to access those with a single host: creating a cloud 3d printing facility.
After a few minutes researching the net for USB to network bridge, I realized the overhead to print via network is possible without Octoprint or some other solution, but simple ser2net and socat alone, thanks to this Github Issue by Marco E explaining his steps, so I reiterate his solution with some changes:
create USB to network bridge with ser2net per printer
create network to virtual serial per printer with socat on the host
Printers
Each printer you like to network has to have:
Linux OS (like Debian, Ubuntu or alike), e.g. Raspberry Pi or OrangePi or any kind of lowcost ARM-based board
USB connectivity where the 3d printer is wired
Wi-Fi (wireless) or Ethernet (wired) connectivity
Install
As next install ser2net serial to tcp bridge per printer:
% sudo apt install ser2net
Create a file named client.cfg, you may have to change the baudrate and/or the USB device:
3380:raw:600:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT -XONXOFF LOCAL -RTSCTS
Start ser2net on each printer:
% ser2net -c client.cfg
Host
As next prepare the host, where all the printers will be controlled from:
UNIX OS like Linux (Debian, Ubuntu, *BSD, macOS should work too)
2018/11/01: there is a slight drawback using ser2net: only takes common baudrates, but doesn’t support 250,000 which is the default baudrate for Marlin, 115,200 does work though. So, in case you plan to use ser2net reflash the firmware to use 115200 as baudrate.
Although 3d parts need to be seen and visually so much is communicated, but Cura’s user interface feels conceptually skewed (“Prepare” vs “Monitor” tab) – and with the time I thought I want an ordinary command line interface to print parts quickly, easily multiply and random placement so the bed surface is more evenly used and not just the center – I have grown tired to move parts on the virtual bed.
So, I wrote print3r, a command line interface which utilizes Slic3r as backend. Its main features (Version 0.0.6):
command line interface, no GUI
UNIX platform (Linux, *BSD, macOS should work too)
print .scad (OpenSCAD), .stl, .obj, .amf and .3mf directly
it converts and slices depending on file format as needed
takes Slic3r command line arguments
multiply part
random placement
scale, rotate, translate or mirror (.scad or .stl only for now)
slice .stl, .obj, .amf and .3mf to .gcode
print gcode files
send gcode lines direct from command line arguments
send interactively gcode commands from the console
render .scad, .stl and .gcode to PNG for documentation purposes
Example
% print3r --printer=ashtar-k-30x30.ini --fill-density=0 --random-placement print Parts/cube.scad
== Print3r 0.0.3 == https://github.com/Spiritdude/Print3r
print3r: conf: device /dev/ttyUSB0, bed 300x300mm, nozzle/d 0.5mm, layer/h 0.4mm, filament/d 1.75mm
print3r: scad to stl: done.
print3r: slice parts to gcode: filament usage 79.67cm, done.
print3r: print: printing 0h 09m elapsed, eta 0h 00m, 100% complete (38494 of 38494), z=19.80mm, layer #50, filament 79.67cm
More information on the printer display: progress [%], eta and layer#:
Printing new X motor mount on CTC DIY I3, and replacing it on the new Ashtar K: CTC DIY I3 prints quite reliably – there is nothing to clean up – the piece I attach it right away:
Ashtar K lacked a proper print surface (before I received the black sticker surface), otherwise I would have printed the piece on itself.
Black Sticker as Bed Surface
The 400×400 black sticker arrived, and I cut it into 400x300mm and put it on the mirror – which worked well, and so far I can tell the surface is very very flat, much better than on alu heat bed.
Current bed setup (top to bottom):
400x300mm black sticker (“frosted sticker”), apprx. 0.6mm thick
400x300mm 3mm thick mirror
210x210mm 12V alu heat bed
various cork patches under heat bed
10mm light black foam material
420x320mm 6mm plywood (white painted) as Y carriage
Now that I have a good print surface I finally printed pieces for itself.
Mounting the 400×300 bed (OSB 6mm, white painted) with 200×200 heat bed (which I hardly use, as I started to print on cold bed):
I currently use the white PU steel enhanced GT2 belts, and it produces hard edges, some ghosting, but more precise prints than the black rubber GT2 belts which just stretch too much – I have to research this more closely – about the type of reinforcement and the use with more heavy beds (Y carriage).
Just for the record regarding Y carriage (2018/09):
420×320 carriage:
4mm plywood flexes, but has been quite flat – not recommended
6mm plywood hardly flexes, but has been hard to buy truly flat – and so far my attempt to flatten it did not work well – not recommend unless it’s flat
6mm OSB quite flat, does not flex much (3 or 4 sliders) – recommended
320×320 carriage (for 300×300 bed):
4mm plywood works (3 sliders, 4 sliders recommended)
6mm plywood works (3 sliders, 4 sliders possible if plywood is truly flat <0.2mm difference)
6mm OSB quite flat, doesn’t flex (not yet tested)
Just to explain my thought or decision process for my setup:
the mirror should not be bend (of course)
the support structure should not be the edge mounts, but the foam in between
the carriage can be bent, but not flex
revelation: already bent means the springs with screws might extend the bent further with a flexing carriage, and not counter act – as the mirror should stay flat
so, even though the springs/screws and edge mount can adjust, the carriage should be fairly flat, and not flex at all – this way the edge mounts holding the glass/mirror only stabilize position. Main force to hold the glass/mirror, for my setup, is the foam in between. So, there is no “spring” induced vibration back/forth introduced, but the foam neutralizes such vibrations – and hardly adds weight/inertia.
Sliders & Belt Mount Positions
Top view with see-through (best mark “0,0” on both sides to keep reference).
400×300 vs 300×300 Bed
Originally I focused on 300×300 bed at least, with some tweaking and narrow X carriage I was able to reach 380×300 printable bed, so it was suitable to use 400×300 plate as well.
It takes me about 5min to mount new bed, downgrade from 400×300 to 300×300:
Changes needed:
move Y endstop switch from left to Y carriage extrusion to the right side
Y stopper mounted on the bed needs to placed accordingly
With 300×300 bed the 0,0 is now plenty outside of the bed, with 400×300 the 0,0 is near the printed bed mount.
Setting Offsets for 300×300 bed
With 300×300 bed the 0,0 is now +32mm to right and +25mm deeper, hence the Gcode M206 is set like this:
M206 X-32 Y-25
H Plate/Module as X Carriage
The 3 wheels module riding on the 2020 alu extrusion I named “V plate” due the shape, the 4 wheels module “H plate” providing more stability or rigidity for use as X axis carriage, when the nozzle runs over slightly unclean extrusion and tilts upside. For the X carriage I choose a narrow (48mm wide hole-to-hole) version:
Belt mount and hotend holder using same mounting holes
It’s the first/early version, the adjustment screws (M3x10) are very or too close to the bed for my taste, next version will use M3x8 and give more spacing. I like to keep the hotend close to the X carriage so not to waste Z space.
Additionally I made a new hotend mount so it would use another mounting holes than belt mount:
Belt mount and hotend holder using same mounting holes
Belt mount and hotend holder separate
But now it’s harder to reach the hotend mount holes due the part cooler – oh well.
After few days, I noticed one wheel stopped to turn, no longer touching the alu extrusion – I guess the carriage slowly balanced itself and triangulized, no longer use the 4th wheel. I re-tighten the 4th wheel gently so it would roll again.
Z Couplers: To Wobble or Not To Wobble
As I posted before, I suspect the Z couplers to be the main source for Z wobbles, as the threaded rods may look and are cheap but they are mostly straight – the wobble actually is caused, after close observation, from the misalignment which happens when you screw the metal couplers on, in particular if you attached the lead screw or threaded rod with uneven surface – the thightening screws may or may not attach cleanly – and thereby push the Z rods out of the center of the Z stepper motor – when the Z thread holding the X axis is fixed, the resulting wobble is worse at low Z heights; and if you fasten the Z rods at the top, the wobble gets even worse.
A simple remedy I found is to use printed couplers, two pieces which are screwed together with 4x M3 screws and nuts, a bit of an overkill, and a bit time consuming to fasten: incrementally tighten each screw over and over until all are tight – but I think it’s worth it: the two halves attach evenly and the PLA or ABS or whatever you printed the couplers, is soft enough so the threads of the Z rods carve themselves evenly into the coupler, and self center themselves this way – result is better centric attachment of the Z rods, not perfect but acceptable and better than poorly manufactured metal couplers.
Alu 5mm to 6mm coupler
PLA printed 5mm to 6mm coupler
As mentioned before, I switched from M8 to M6 for the Z axis the M6 provides 1mm movement per full turn, and is more flexible to even out out-of-center wobbles, better than the stiffer M8 threaded rod. If using couplers at all, and likely introduce out-of-center mounting, rather use a more flexible lead-screw or threaded rod than a stiffer one.