Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/173 Thanks!
Hello, everyone, and thank
you for being here on this early Sunday
afternoon.
I would like to give you a little
presentation.
But first, a little introduction.
We are open 3D engineering from
Berlin. My name is, but I'm the priest.
This is my colleague Marcus Winkler, who
will do the second half of the
presentation.
And our third man is who will Silva,
who is currently in Portugal for
visiting his family.
And we our
work is to
to work on open hardware, to improve
it and to promote it.
And the last year we worked on 3D
printers and we developed
our own redesign of of a wrap
wrap. The Prusa i3 and
we redesigned it into the
i3 Berlin.
And while doing so and also producing
this and basically
selling it, we run into
quite some challenges that I
would like to share with you.
There there's one
problem with hardware
compared to software, and that is that
copying hardware just takes a
lot more time and a lot more money
than is the case for
about four software.
So you run into some
difficult points when
you go through the whole cycle of
developing your your product.
So it all starts with the design.
So you start thinking, OK, maybe
I need maybe I need a Klemperer
tool to hold this filament because it's
so messy and then you design this file.
But it should also actually fit, and it
should not only fit on this printer, but
it should also fit on on a different
printer. So you have to take care of
tolerances and things like that.
And maybe you have several different
ideas, so you have to keep track of that.
So also to share and inspire
other people.
So you have to track your versions
and make log files, basically, which
is kind of the same as in software, I
think.
And after your idea
basically settles and it becomes all
real, then you have to also
document it because it's not pressed
the install button.
And there you have a functioning product.
No, it's you have to put it together and
people have to somehow find the right
screws somewhere.
And this is all has to be documented
to include other people and
users. Also into your
your project.
Where it becomes even more difficult is
to manufacture is like I.
It screws, cost money and
they cost a little less money if you buy
a whole lot of it.
But then you also have to be sure
that if if you want a 3D printer
that I have these screws in my
place and then
you run also into delivery times and
things like that, this all has to be
organized and
it's a challenge.
And then you have to sell it, which is
also boring, and then you have
to manage the quality.
So also does the printer still,
which is a mechanical device which moves
so things wear out?
And does it also still work a month
after? So this is all
a lot of problems that has to be managed,
all centered around your core data,
which is the 3D printer in this case.
Of course, these problems are not new.
I would like to tell you a little bit
about the PLM concept
or product lifecycle management
concept.
This comes from the car industry,
from American Car
Motor Car Corporation,
from Chrysler and all these big brands.
When they developed in the 90s,
one of the first SUV I saw there was
the Jeep Cherokee or something.
They had the aim
of innovating
faster and cheaper.
And to do this, they wanted
to have very big
information backbone around
the whole product so
that the engineers designing the product
and also the engineers responsible
for manufacturing and also the people
responsible for selling the whole
team of people involved
in this project knew
what was going on and could influence it.
And it was very efficient because
they could do basically the
whole development in half the time for
half the money.
And it's actually quite funny
because such a big company is a
kind of Open-Source Micro
Cosmos where it's really focused
to share a lot of these data.
Of course, until the front door, and
no one should bring it on the street.
But inside of this company, it's
to make it more efficient is to to
share a lot of data.
So I think we as open source people
can. And can learn a lot from that.
And of course,
the bigger your project gets
also the the more data has to be
managed and the more difficult it gets.
And if you have a very small project,
it's it's not so difficult.
We have a kind of a medium,
simple project of a 3-D printer.
And in the next part of the presentation,
Morris would like to tell
a bit more about how we
try to implement this in our
project.
Hello.
And there was Morris
and uh, yeah.
First, I would like to say a few things.
Um, well, we're talking
with other open hardware projects.
Um, we realized that
there's actually a lot of
problems regarding just how to manage,
um, your thoughts of how
to manage your production cycle and
that there is not really a general
solution. And well, when we started
to invest time into this project
and, uh, started to look how to
structures, we also realized that
it has to be very customized so you can
have a basic template of of an idea,
but you can't have really a tool or
one one tool that will
manage all of all of this for this
for you.
Because, um, every project is
very unique and has very unique
dependencies, very unique needs.
And so I think in the end, everybody
has to find its own approach
to this. But we want to show
an example of how we do it, and I think
it can be laid out for the other
projects, um, to start with.
So basically, when we do our
design process, we have a few, um,
main types of files that come on out
through the design process.
So we design mainly in blender,
um uh, it's the open source
3D modeler.
Um, so in
Blender, we design the
parts that we print on the printer.
So there's many parts on the
printer that are printed by the printer
itself.
Um, we,
um, make the whole assembly
in the blender file.
So we have all the parts in a blender
file and we already check if it actually
can be assembled and how to assemble it
before we produce it.
Um uh, we we
check how many pots we need.
So we have some tools in blender to
count, actually, how many pots we have in
here, how many pots we need to create
this, um, this printer
and we use it also for documentation.
Um yeah.
But I will come later to that.
Um, then we have, um,
cut files for the
frame. We are missing the frame.
So we have cut files, um, that we can
use to to fit in a thin Cemil
um.
We have firmware which we
don't produce all firmware.
We don't write our own firmware.
But in, uh, for 3D printers,
you basically have like five flavors of
different firmware.
And what we do, we
we calibrate because there's lots of
settings in the firmware and we prequel
liberated firmware to our printer.
So if you want to use it, you just
download the firmware from our repository
and you just install it.
You ready to go?
And what we also have
our settings.
So um.
Because there is a lot of different tools
to take 3D models and translate
them into into what's called G codes,
that article month that the printer can,
um uh, can
understand and interpret.
And these tools, they have a lot of
different settings, so it's very
difficult in the beginning to start
using them. And so we have presets of,
uh, settings that we give out
to our users so they can start right
away printing with the printer.
Um, yeah, awesome.
Um, what basically does digital
fabrication? So everything we
start everything with the file on the
computer. It's created with a programmer
and it has really, um
yeah, it has some very nice, um
um, parts
on it. So basically, if you
have files, you have directories, it's
very structured. You can find things,
other people can find things.
Also, um,
you're ready to go to a bigger
manufacturing process, so you have source
files that you can send to a company
or to somebody that has a bigger
manufacturing capabilities
and you can start processing them right
away so you don't have
a you don't spend a lot of time to scale
up.
Um, you can have
tasks that are assigned to different
um, people or different into
individual team members,
but still everything can
be reviewed by everybody.
Yeah.
So, um, for example, promise
the uh.
The engineering our team is doing mainly
the mechanical engineering, but every
time it changes something, I can have a
look and look actually what you do and I
can review it and give it some
feedback on that.
That's very nice.
So
to structure all this, we use it.
It's a very
nice tool as decentralized.
So basically, it's very difficult to lose
information. Everybody has a copy of
everything. So only
in the case when everybody lose it at the
same time, you will lose all your
information.
Um, we have comments
that help us understand what actually
happens in the repository.
So if somebody changes something, it gets
a little comment and say, Look, I did
this and this and that.
So we actually know what's going on at
certain moments.
You can branch out.
So if somebody say, Look, I like this
printer very much what I think, I can do
it in a different way, or it can improve
something. You can create a device,
you can for it, whatever.
And we have texts that help us,
uh, creating versions so we
can, uh, take a certain moment in time
and say, this is version 1.0.
It's stable and you can use it.
Um, we don't use
it right away.
We use actually, we use GitHub,
which is more tool for for software,
but it's basically the same
if just source files and GitHub
brings a few nice tools with
it. So in GitHub, you have desktop
clients that facilitate
the use of Git because, um,
well, we have a um, I myself, I'm
a software engineer, performance and
mechanical engineer or certain member
of industry, uh, product
designer.
So they are not all where we used
to use a version of
the vision systems.
So it certainly takes a lot of people to
get into it.
Then we have the issue tracking on GitHub
that we use it all ourselves to
track issues with the product.
Um, and our users can also
come and say, Look, you have a problem.
You can even say we found a fix.
Or at least we know that there is a
problem.
Um, we used to.
Vicki Page is very much in GitHub.
Um, we do them
use them and ASCII door, which
allows us to export them after and oxygen
and generate all kinds of, uh,
documentation formats.
From this, it's very, very useful.
And well, we can do releases in GitHub
and add additional information to the
releases.
Um, so the other reasons why we choose
GitHub, uh,
were, uh, over getting a repository
in our server, um,
documentation. It's a very important
point because when you have
open hardware project, you want
to get it out to people who want to use
it because, um, real problems
that you would not have seen before.
So if you want them to use it, you really
have to document that. You have to tell
them how to use it, how to create it.
Um, and it's
um, we very much try to automate
this. So we have basically
all documentation comes mainly out of the
blender file, which
makes the planner file sometimes
even a little bit messy.
Um, and sometimes even a little bit
difficult to work with.
But on the other hand, it takes a lot of
time off of the documentation process.
Um, one very, very important part of
documentation for hardware projects is
these so-called bomb.
It's the bill of materials
and bill of materials basically is a
spreadsheet where we say, I need
to spruce up this time to
borrows from this kind.
And the good bomb also lists
devices and places where you can buy this
stuff. So if somebody wants to
recreate it, recreate the project
and then also place, you know, I can
order the stuff there, the stuff here,
the stuff there, but also helps
us a lot to keep actually track
of what we need to create one unit.
So for example,
um, we change something in the blender
file.
The bomb and the blender are linked
together. And um, this is also
in professional, computer
aided engineering.
This is taking very much care off
because, um, you tend to make mistakes
if you have to do this manually.
If you change something in the blender
file and after you think, OK, I need for
more screws of this type and you have to
edit in the in the bomb file, you tend to
forget about things or you have
communication problems.
And it's really nice if if,
if these two things are linked because,
you know, actually all
the time what you need to create one unit
also if you change things.
And then what we have also
in the blender assemblies will be
basically your frames and blender.
They're used for animation
and we basically start we start
with frame one and frame one.
You have the first two parts that have to
be assembled in frame two.
We have, um, the third
part that gets added to it.
And so it goes on and on and on and on.
And I think somewhere about frame
one hundred, you have a
completed unit, and we use
this render these images in Blender,
um, put them into the GitHub wiki
and then we document this with text.
Yeah. And so we create our documentation.
So this helps us a lot.
If we if we change things over time,
we can very quickly add up our
documentation and we basically
we have to make Makefile that exports all
the friends from the blender and,
well, the text you have to edit manually.
But it just makes the process much
more liquid.
Um, and then from the GitHub
with you, you can browse the directory on
GitHub. You have the documentation there,
but we have also the possibility to use
a tool that's called Get Scribe that will
convert the ASCII doc
on GitHub into Dr. Jenman from the oxygen
you can go wherever you want pdf,
epub.
And there are a lot of formats you can
export directly from the oxygen.
So, um yeah,
uh, it's very helpful for documentation.
And um,
I think it cuts us down half
of the time for documentation.
We still need a lot of time for
documentation, but um
yeah, we we have a very small
project. You really have to look for
this. Uh, I think the last
recommendation we took altogether one of
months to put it really together, it's
a lot of time. But um,
the organization always takes a lot of
time.
Uh, resource
allocation. Is this when you
actually, um,
create a hardware, you have to think
about how many parts I need,
where I get them from or higher
manufacture them, or how to do them
myself. And um,
well, we have, um,
basically again, the planner file here
in the blender file. We have, um,
certain layers where all the printed
parts and we can just take those layers
and um, export
files that we print on the printers.
So we take care of that in the planner
file.
Um, we have to
cut files where we create
or frames the
all the measures, put the frames and
rebuild them.
Um, and then we have them again.
The most important tool for that is the
bill of materials.
Um, because it's
already spreadsheets.
And so we basically work with a lot of
other spreadsheets.
We put it into other spreadsheets
and, um, uh,
kind of manage our stacked stock with
this. Or when somebody
comes and say, I want to have ten
printers, you can really look in,
what do I have in stock, what I actually
still need to order or what do
I need still to manufacture myself
to actually deliver, um, these
units?
And yeah, it helps a lot.
If this gets a little bit automated, it's
it's so specific to every project
that it might be difficult to automate
this. But um, you know, we only use
spreadsheets for this.
We haven't found any tool, all the all
the tools that are available yet
so complex that you spend three to three
times more time to use them
actually than we did in the time you
get out of them.
So this is the part where
it gets very, very specific to the needs
of the project.
Um, you know, just
as a as a note, we have two
hundred eighty four parts currently in
one printer, so we have to take care of
all of the parts that they're basically
in stock.
Um yeah.
Sales is um, well, you can.
You can bring out you your hardware in
many, many different pressures.
When we started, we decided on workshops.
Uh, we wanted to do workshops, and I
think it's a good way to start with
workshops because you get the immediate
feedback.
OK, I'm I'm hearing if you get
immediate feedback, workshops are really,
really good because you experience
feedback that you won't get in all the
way. Um um, we
have also feedback through people that,
uh, write us, uh, tickets via feedback.
So people that send us mails sometimes to
phone us. And so we have this feedback
in the workshop.
We have a two day workshop where we
every month have around 10 people going
through and really see where the
difficulties we see the difficulties
with assembly.
We are difficulties with installing
software.
We are the difficulties in using the
printer. And so this is a very, very good
feedback.
Um, we have at
some point we created the online store
and this was because we got a lot of
requests from people if they want, if
we send them out kits because it wouldn't
come to our workshops to decide to do
online store.
That's um, well, very technical you
something you should think about if
you want to create something like this.
And since one month, we also sell them
in a in a little store in Berlin that
sells 3D printers.
But of course, there are many, many other
ways to get all your hardware, but you
should think about ways to get it out
because you want people to use it and you
want to have feedback that you otherwise.
Get,
yeah, all good quality management,
that's basically about the feedback,
and we have
a lot of direct contact, and I really
liked it. I really liked the direct
contact because it just gives you this
kind of feedback that you don't get.
Yeah.
Also, we still have a lot of
private contact with a few of our
customers that we meet and
they tell us about the experiences
we have, of course, the ticket system
and we have mails.
We have, yeah, and we have long time
tests, the ones you actually
produce to the machine and you work over
time with it, you will find problems
that appear only in long time
that OK, you only if you use it six
months or eight months.
And um, well, all
this information gets compiled and we
will do two things with it.
We we um, we enhance the
documentation because we get a lot of
ideas out of it.
For example, we try to make the assembly
more easy, more organized
and more simple,
less depth.
Um yeah.
Sometimes you have steps that you do
later that you should have done earlier,
but you don't realize until you see
somebody doing the steps.
And we have frequently asked questions
because the questions that come up all
the time, again and again and again.
And so you should provide people with
answers to that.
And what, of course, what is the outcome
of it? It's like the place where to sort
of close. It closes and you go back
to the drawing board and you realize,
Okay, this thing can stay like
that. We have to change it.
So you go in again into redesigning
or designing parts of it and you go over
all over and the circle starts from the
beginning again.
Um, so far, the quality management,
your part?
Yes. So that was
our story on how we
tried to make this not
so easy a
project into
a kind of organized structure with as
little as possible, which of
course takes a lot of work.
So there is a balance you cannot over
structure because that you cannot do your
work anymore.
And while doing this, of course,
we have some ideas how we want
to improve ourselves and also how we
what we can say to other open hardware
projects.
First of all, design sharing is
a critical node to ourselves is we should
take more care to
to have it really accessible for
everyone.
We do some special screws.
We use a CAD software
that is quite unusual blender,
but also we want to share it not only on
target, but we should also share it
on on bigger platforms and in bigger
communities. So there is a bigger chance
of other people coming in.
And then, of course, the the whole
documentation becomes more important.
And that's also the other thing that we
want to do. There is a lot of talk about
documentation in the open hardware
community and there is still
not not the
the the the holy grail has not
been found yet because
contrary to software and software, you
can just write in things
because you are writing anyway and
hardware, it's it's not as
simple as that. So documentation
is just a lot of extra work.
And so
that's also why we want to write more
about our documentation system for
others to to learn from.
And last thing that we want
to do is to look for or to develop
some kind of database and other tools,
especially for our stock management,
because this consumes most
of the time, so too, to write
your bills and to see if
all the screws are there.
And and and and and
which is annoying.
And this all
we want to do because it
is really needed for open hardware
projects for good quality open
hardware projects.
So small initiatives
like us have a better
chance in competing with
with bigger, more commercial
propriety companies.
And
we think that's good because it's nice to
have your own company and
to do stuff that you like.
There was basically a presentation.
We have two minutes left, so
we would really like to hear from you
some questions or comments or
things like that.
Any questions?
Don't be shy.
And the questions from the internet?
No.
Anyone else?
Come on. You got to have
what they said. What
was it? That's clear.
Really
cannot imagine as long as
that, we have to say.
Well, excellent,
thank you very much. Microphone number
one, one thing I worry about,
like what kind of people are
working with your 3-D printer
developing and are you just like
a computer scientist or also some
mechanical engineers,
the people using the
printer? No, no.
Like your group with
we are three people and mechanical
engineers. Software is a software.
My mother is a software engineer
and Hugo is a industrial
designer, small for the looks
about stuff.
So we have quite an interesting team to
to work on something like this.
And so do you get along
well with the version control system?
Because like I'm a member of Robotics Cup
at our university and sometimes
our mechanical engineers really mess up
stuff, mess up the history.
Was that easy for you to like, get into
it? Or, you
know, it's not easy.
It's it's difficult.
It's as
it's always from different disciplines.
You have always different ways of
organizing your work, and
this also comes with personality.
So it's just that's difficult.
Do you think there's something that could
make it easier to get started
with very control systems?
Or is it
that I mean, that's what we should use
GitHub also because you have data plans
or to use share a lot.
We just throw things in
and take them out.
And you don't have all this command line
gets craziness there,
and a lot of people have problem with
this. So we like to use tools to work
on top of that.
Yeah. And how does that work with the
blender files? Are they binary or are the
text based
the binary, as
far as I know. So you get history
is getting really big with the binary
files thing.
So it's OK.
You call the
president a lot.
OK?
And do you think there is any possibility
that one day we could have something
like like this for
like mechanical files like
that you could use?
And whether you have this
already for mechanical flight, if you use
open escort, you can defeat them.
Yeah.
But um, well,
I don't know any um um uh,
3D software that you could defend any
way. And it might be possible
for kids to write this approach.
And you write as if to forget that use
blender files.
But um, well, I
think it's very kind of can be very
difficult and usually it's like this.
Did you have somebody that or you have
a small group that is dedicated to do
this stuff so
you don't really need that so much?
Um, it's more it makes more
sense if you have a bigger group to write
actually a pipeline system
that you can work together in the in the
cut software.
Yeah. Yeah.
Thank you.
Hello. Hello.
I'm an engineer.
I was a little bit surprised.
I expected to hear something
about agile and agile development
about you, the MF Project
or open source project
software and so on.
And I see that you use
get a sort of backlog
in the means of agile software
development so that the way you
put it and take it back
for other
end software is also organizing.
The professional won the women's
and so on.
They use their system
to to handle all of the
design for the fiddy stuff,
and it's now in databases.
And if you now come as a
guy before me and use
a text oriented
thing like get
any system for binaries
where you have then to import again into
your blender and so on.
Um, I'm a little bit of a surprise, so
please tell us about the project
management, where usually the people use
open source or not open source project
to do you do something like this tool?
Not there are.
Look, if you look at, um,
professional people and systems and if
you look at the open source, I look
through a lot of oil actually through all
the open source systems that are
available.
And the problem with them is that they
are all so complex that they eat up more
time than they give you through spending
so much time implementing the system,
getting everybody used to it, actually
filling out all the forms that you have
to fill out to enter one part into any
system that you spend, like three hours
and winning 20 minutes.
So it makes no sense.
So I think, first of all, makes it
logically got a lot of open up project
a very small. It makes much more sense to
simplify that stuff a lot to make it as
simple as possible because you don't have
a time to spend so much time on
organizing your lab.
Yeah, I
heard about University of Hanover,
where is a very unusual
output cut, was
taking its 10.
But group of former students to attend,
forming a student students of the
building think causes a noncommercial
pleasure.
Um, and because this outer
cut system allows him to
like GitHub in the software
world to take parts out
and then in a sort of simulation
to put it together well, while other
processes and systems
offer competitors which are very
expensive and so they don't allow this.
So you can't further.
The collaboration of work was
with other classes, which nobody
in the mechanical engineering likes
otakaro. But this was the argument again
to take all the cut there.
But this is the this is called why do
we have? This is called pipeline
and pipeline, and you have also you could
implement pipeline in the blender,
although there are students that use
blender that have a pipeline lighting
system put in the pipeline and basically
give parts because in the in
a blender fire on a cut price, everything
a tree structure so you can go into
a speech structure or object
and push them over to somebody else or a
database, it is completely possible.
Um, there's just no tools like this
blender. There are tools for this, for
AutoCAD, for, um, for
a list. A lot of tools for this,
um, for, um, all the
professional uh and
inventor systems to have that.
But there's no open source system.
And in 3D modeling, there are a lot of
pipeline systems, but they're all
customized.
It just that you won't find the
labeling system that works for everybody
the same. They're all customized to the
certain studio that uses it, but it's
completely possible.
OK, misdirected
yourself. It's important for you that you
have an open source
software design process, and
the design is
open source. And not just say
we get money, but open source because
it must not be unpaid.
That's why we use proficient, which
probably tell you, but the
output you what we work for,
we demand by our customers
that it is open source or whatever.
So you have everything must be of open
source, right? Or maybe the customers
take your life and
the proprietary product project
products where you are paid
and they get the sources, but
they don't say, no, we don't share it
with our customers because nobody
buys the washing machine once the open
source code of
the machine.
Mm hmm.
Did you get,
um, I'm sorry, we're running
out of time. So if you'd like
to come, try to pursue that
question outside.