Experiments in live computational sculpting
There's a forum on https://talk.lurk.org/channel/liveprinter
You can join our email list to keep up to date with performances, demonstrations, workshops, and important updates.
Evan is on Twitter at @evanraskob and can answer questions, etc.
We can create a Reddit forum or YouTube channel if there is demand for it.
A quickstart document can be found here
The server runs on Python 3 (3.6 and 3.7 tested) so you will need that installed. Then, use pip (the Python package manager) to install:
- pyserial (tested with 3.4)
- tornado (tested with 6.0.1)
- tornado-jsonrpc2 (tested with 0.5)
Here is a short video demonstrating the python installation on Windows (on OS X it's the same, just use Terminal instead of Command Prompt): https://youtu.be/ejlaQhOCUHw
Run the server using your Python environment of choice * it's in the liveprinter folder, called LivePrinterServer.py. By default, the server runs on port 8888 so open a web browser to http://localhost:8888 (or change it). It can run without a printer using a "fake" serial port.
LivePrinter is an open source system for live, immediate drawing and fabrication with 3D printers. Itβs particularly useful for:
- Textile artists who want to print onto fabrics and make new shapes and textures; for artists who want to use a printer like a 3D plotter and draw new forms
- Product and industrial designers who want to understand more about how 3D printing works and fine-tune their materials and tool paths
- Materials scientists who want to study 3D printing materials in more controlled, repeatable ways
- Computational and computer artists, either looking for new tools or making generative works
- Educators who teach fabrication
- HackSpace and MakerSpace staff who need more tools to fine-tune their machines
LivePrinter combines the design and 3D printing of objects into a single, iterative process. Livecoding is used to control manufacturing precisely and procedurally with real-time flexibility. It brings improvisation and intuition to the act of making new computational forms. The system extends digital printing and CNC machining into the realm of performance and also has potential in design and science pedagogy.
The current software toolchains of 3D printing place the artist and designer at a difficult distance from the physical process of making. There is little space for live improvisation and experimentation, especially with key properties that directly affect printing materials, like temperature and print speeds.
You can watch a video of LivePrinter in action, running experimental tests, creating generative shapes, and exploring printing in air:
LivePrinter is designed to be:
- Flexible in deployment: it should run on as many platforms as possible (Raspberry PI and other Linux and RTOS systems as well as standard computers such as desktops and laptops)
- Easy to hack: the system architecture itself should not have too many dependencies or be generally too elaborate and complex. It should stick to minimal, necessary features. It should favor less code files that do more over many files that interact in complex ways. Important code that will edited often should be foregrounded. This goes for the livecoding mini-languages as well.
- Allow for as little lag as possible: physically making things happens in realtime, and even milliseconds count when you have melted plastic cooling.
- Be quick and intuitive to code: the livecoding system should be as minimally-verbose as possible so it can be typed quickly. It should also provide enough core, useful functions so that common making actions are supported.
- Be as honest as possible with physical states: the code should not try and cache physical properties like temperature and print head position, for example. These relate to instantaneous reality and should be treated as such. A query/response system is one such solution.
- Be understandable and appropriate for artists, designers, and non-technical people: This is a (fun!) tool for making intuitively, and the language should reflect that, even at the expense of technical accuracy (of language).
- Be collaborative, social, performative: Allow for others to take part in the making process, whether that's contributing directly to the livecoding or spectating as audience.
LivePrinter is part web client and server for livecoding and part 3D printer host application on the back end. On the front end, a user will livecode in a web browser (or other web client). Their code is compiled into machine-appropriate G-Code, packaged into JSON-ROPC calls and sent via AJAX (http) to the back end, where it is sent to the printer via a serial connection. Responses from the printer are sent back to the web client. This whole process is asynchronous, for speed and for tracking which messages successfully were send (and responses received).
More than one person might be involved: the system is designed to support collaborative livecoding and potentially many 3D printers, as complex as that is! (Look at the Max/MSP example in the misc folder for an example of this)
If you fire up the server and then navigate a browser to http://localhost:8888/jsontest you can play with the API in a hands-on web page.
This is what the API looks like currently:
- send: { "jsonrpc": "2.0", "id": 6, "method": "get-serial-ports","params": []}
- receive back array of port names: {"jsonrpc":"2.0","id":6,"result":{"ports":["COM3","dummy"],"time":1568371926204.6528}}
- send port name (e.g. "COM3") and speed (e.g. 25000): { "jsonrpc": "2.0", "id": 5, "method": "set-serial-port","params": [ "COM3", 250000]}
- receive back connection results from printer (if any): {"jsonrpc":"2.0","id":5,"result":[{"time":1568375167280.751,"port":["COM3",250000],"messages":["start","echo:Marlin 1.0.0","echo: Last Updated: Dec 8 2018 13:25:37 | Author: Version DEV","Compiled: Dec 8 2018","echo: Free Memory: 2123 PlannerBufferBytes: 1232","echo:Stored settings retrieved","echo:Steps per unit:","echo: M92 X80.00 Y80.00 Z200.00 E282.00","echo:Maximum feedrates (mm/s):","echo: M203 X300.00 Y300.00 Z40.00 E45.00","echo:Maximum Acceleration (mm/s2):","echo: M201 X9000 Y9000 Z100 E10000","echo:Acceleration: S=acceleration, T=retract acceleration","echo: M204 S3000.00 T3000.00","echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)","echo: M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00","echo:Home offset (mm):","echo: M206 X0.00 Y0.00 Z-12.15","echo:PID settings:","echo: M301 P10.00 I2.50 D100.00"]}]}
- send any GCode (e.g. "G28"): { "jsonrpc": "2.0", "id": 4, "method": "send-gcode","params": ["G28"]}
- receive back results from printer (e.g. "ok"): {"jsonrpc":"2.0","id":4,"result":["ok"]}
- send: { "jsonrpc": "2.0", "id": 3, "method": "get-printer-state","params": []}
- receive back: {"jsonrpc":"2.0","id":3,"result":[{"time":1568371930335.6362,"port":null,"state":"closed"}]} or {"jsonrpc":"2.0","id":3,"result":[{"time":1571916551445.2378,"port":"/dev/null","state":"connected"}]}
- send: { "jsonrpc": "2.0", "id": 2, "method": "close-serial-port","params": []}
- receive back: {"jsonrpc":"2.0","id":2,"result":["closed"]}
- liveprinter.js: handles the user interface and communication with server (sends GCode, handles events)
- printer.js: the 3D printer API (outputs GCode to be sent to the printer)
- LivePrinterServer.py: The back-end web server (uses tornado and websockets), implements the JSON-RPC API
- USBPrinterOutputDevice.py: the Marlin driver that handles serial communication
The back-end web server and websockets service uses a Tornado server written in Python and a very-adapted version of Cura's 3D printing driver that connects to a Marlin Firmware based 3D printer (currently tested on an Ultimaker 2+) and on various Prusa printers, as well as homebrew Marlin-based ones.
A more complicated architecture diagram:
If you want to get involved, please give us a shout! The more the better.
There is an API and function reference for the client end which needs formatting work.
It makes sense (in general, not just for this project) to do Python development using isolated virtual environments, to prevent contamination or clashes between modules and utilities by keeping all configuration sandboxed. This requires a global installation of virtualenv
. After that we can do (on macOS and Linux at least):
virtualenv --python=python3 ~/Desktop/venv3
# create a Python 3 virtual environment
. ~/Desktop/venv3/bin/activate
# activate the environment
pip install --upgrade pip
# get the latest pip in the virtual environment (probably not essential)
pip install tornado pyserial json-rpc
# get the libraries we need
python LivePrinterServer.py
# launch the server in the Python 3 sandbox
For Windows:
virtualenv --python=AppData\Local\Programs\Python\Python37\python.exe Desktop\venv3
Desktop\venv3x\Scripts\activate
Then when all is done:
deactivate
# wind down the environment
LivePrinter is completely open source (AGPL 3.0). To summarise, it is built on and inspired by other open source projects:
- OpenGB has been an inspiration
- Fabrica, a front-end for Smoothieware looks interesting. Smoothieware integration might be nice, someday.
- CNC.js
This project was started by Evan Raskob, artist, livecoder and Lecturer at Goldsmiths University (previously at the Royal College of Art in London), and part-time PhD student in arts and Computational Technology also at Goldsmiths. This project is the main practice part of his ongoing PhD study. If you'd like to get in touch, please email him at [email protected].