Page 82 - ESAM-1-4

Engineering Science in
Additive Manufacturing TwinPrint: Dual-arm robotic bioprinting

same printing workspace collectively. Hence, the printing information on the screen. Additional methods are
area is not necessarily doubled by using dual arms as added to those classes to perform side calculations,
one might previously assume. Both arms must reach the e.g., based on the user’s inputs, feedback from a device,
entire print area. On the other hand, if the print is not and communication with the APIs. Therefore, there are
divided layer by layer and instead, divided from the X or Y intensive background operations and constant requests to
dimension, then the printing area can be doubled. Hence, update the GUI within the system that can cause a delay
the maximum print area is a function of the allocation of in providing updates on screen or even worse, cause GUI
printing sequence to both arms. At minimum, it could be freezing or crashing. To avoid these issues, threading,
the same as the printing area of one arm, and at maximum, which is a locking mechanism, in addition to the pub/
it could be doubled. subapproach is applied.

2.4. Microfluidic syringe pumps integration Most system calculations are dependent on the results
of other calculations that can occur in other parts of the
A set of Cellix ExiGo microfluidic syringe pumps system. This makes the adoption of the threading approach
®
(Cellix, Ireland), consisting of four pumps, is connected ideal, as the threads can share the memory space as well
to the TwinPrint GUI via a USB cable. The computer port as expedite execution time. In addition, it avoids the issue
number and the unique addresses of the pumps are used for of an unresponsive GUI. Hence, background operations
bidirectional communications in a master-slave approach are allocated to threads, called worker threads, and each
without confusion. An API containing all the functions has a certain task to do. The threads may request to update
necessary to operate and handle communications with information on-screen according to their tasks and results.
pumps is created in Python. The pumps can be operated Another thread, called the GUI thread, is responsible
synchronously with the arms, or separately as a whole set for making the GUI appear on-screen, is dedicated to
or individually. Flow rates are set for extrusion depending interacting with the GUI screen. A single Python class
on the viscosity of the biomaterial used. method is allocated for coordinating GUI update requests
Overall system performance can be hampered due to prevent simultaneous screen updates from multiple
to continuous monitoring and updating of individual sources. Furthermore, a locking method is applied to the
pump statuses to the GUI, considering that there are GUI updating class to permit only one update request
eight pumps in the system. To reduce the communication to be received and executed at a time. Furthermore, to
overload, one query command, called “Status Word,” is establish efficient, instantaneous communication between
used to return information about the entire set rather than the various GUI classes, the pub/sub approach is utilized.
query-specific or pump-specific commands despite their 2.6. System tests
simpler, straightforward responses. Further calculations
and conversions have to be done to extract the useful After system design and development, a series of tests were
information from the Status Word’s response. The backend conducted to evaluate TwinPrint. For the evaluation of
code requests an update on the screen only if a pump status printing accuracy with dual-arms, several pen tests were
has changed from the previous received status, which performed to draw different shapes and compare them
eliminates the unnecessary communications with the GUI. with single-arm results (section 3.2). To ensure seamless
pump communication, an experiment was set up to
2.5. GUI compare flow rates run by TwinPrint and SmartFlo —
®
the default pump software (section 3.3). For dual-arm
The GUI Python toolkit used to build the TwinPrint GUI synchronization, an acellular 3D printing experiment was
was wxPython. The GUI layout and features incorporated conducted (section 3.4). To study cell viability, a disease
into the TwinPrint GUI were selected specifically based on model was created using cellular 3D bioprinting with
past 3D bioprinting experience over the span of 5 years, to multiple cell types (section 3.5).
suit researchers’ needs in the Laboratory for Nanomedicine.
The design was developed from a user’s perspective, i.e., 2.7. Acellular 3D printing and cellular 3D bioprinting
what the user would need for easy control before and of a disease model
during printing. Pre-printing, several parameters are set We performed acellular printing experiments as described
by the user, while during 3D bioprinting, the user controls in detail in section 3.4 to test the material deposition of the
the devices and monitors print and flow status.
system and print resolution. For the cellular bioprinting
The user interface is based on classes that inherit experiment, we printed using two cell types to mimic a multi-
attributes and methods from wxPython classes to create cellular disease model; acute myeloid leukemia (AML) cell
and manage the GUI widgets as well as display updated line (HL60) and human bone marrow mesenchymal stem

Volume 1 Issue 4 (2025) 5 doi: 10.36922/ESAM025410025