Open Source Ecology - User contributions [en]

Pieter log

2020-07-05T10:58:50Z

Pieter: /* Sunday 5 July 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

{{Hint|see
[https://ose-workbench-platform.readthedocs.io/en/latest/ ose-workbench-platform] and [https://ose-3d-printer-workbench.readthedocs.io/en/latest/index.html# ose-3d-printer-workbench] for related work on ose documentation generation, git, and versioning}}

= Saturday 5 July 2020 =

Final edit of a couple of video's for the KiCAD/Arduino tutorial.

= Saturday 4 July 2020 =

Recording various clips for the KiCAD/Arduino tutorial for the minimal Arduino with an LED.

Teaching myself FreeCAD. Trying to figure out how to create my own tool with Python scripting. Recording macro's is easy, but to actually create a tool is more difficult.

= Tuesday 30 June 2020 =

Creating a pop filter with an embroidery hoop for my microphone. The P's are now acceptable.

= Sunday 28 June 2020 =

Adding clips, recording voice for the Arduino/KiCAD tutorial with a new microphone. The microphone is good, but the P's are horrible. On pronunciation of a P, the recording clips every time. I need to have a pop filter.

= Saturday 27 June 2020 =

Working on the KiCAD/Arduino video tutorial. First making the notes for the minimal Arduino powered by an LED.

= Tuesday 23 June 2020 =

Meeting with Benedikt, Moritz, and Robin. We discussed several benefits and drawbacks of the Nextcloud, Gollum wiki, and the current OSE wiki. The current OSE wiki supports authentication and authorization. Authentication means that you can identify yourself, for example with a password. Authorization is slightly different; after having been authenticated, authorization defines a policy on who can do what. Traditional wiki's elevate the level of authorization automatically based on contributions. For example, a new user is not allowed to rename a page. However, after several contributions a new user is automatically authorized to do so.

Gollum supports anonymous contributions but appears to not have sophisticated ways to do authentication/authorization. In addition, to make a distributed infrastructure, it should be possible to fill the content of the Gollum wiki based on multiple git repositories. This may be possible with git submodules, but git modules are supposed to nest git repositories and remain fixed on a specific commit of a different repository. This is a bit different from what Gollum should support because you would want to host a specific branch and follow that branch. Perhaps this is possible by creating an automatic pull script.

With all this in mind, I concluded that I like my original idea:
* Move development of machines to git, for example github
* For each machine, have a dedicated git repository with
** licencse
** readme
** Makefile
** submodules for dependencies (for example the universal axis is a submodule of the 3d printer)
* The makefile generates documentation:
** A build manual
** A wiki page
** Images for the FreeCAD files

I'm going to experiment with this for a next meeting.

In the meantime user [[User:Groques|Groques]] has hinted to me that he is also working on versioning from a bit different perspective. We definitely have to talk about this.

After the meeting I have been experimenting with [https://pandoc.org/ Pandoc] from [https://orgmode.org/ Orgmode]. Orgmode is a file format supported by a 'mode' for [https://www.gnu.org/software/emacs/ Emacs], a widely used editor. It allows you to write TODO's, notes, presentations, academic papers in just normal text, similar to [https://www.markdownguide.org/ Markdown], but a bit more powerful, especially with the support from the editor. For example, Org files allow you to create tables and spreadsheets with column and row formula's, automatically computing values. It supports code blocks in many languages and these code blocks can be executed from the document and the code blocks can even interact with each other, even between different languages.

I documented the Nextcloud installation file in Org mode and with Pandoc I transformed it to the wiki format. Unfortunately, this wiki does not support code highlighting, for some reason, so I had to adjust the output slightly.

The result of the Org mode to wiki format translation is here: [[Install Nextcloud on Arch Linux]].

= Sunday 21 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Saturday 20 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Wednesday 10 June 2020 =

Meeting with Holger and Benedikt. Benedikt also invited Robin from OSE Germany and Moritz. We discussed alternative digital infrastructure setups including the Nextcloud instance that I created, creating a wiki powered by git, in the form of [https://github.com/gollum/gollum/wiki Gollum]. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-07-05T10:56:06Z

Pieter: /* Tuesday 30 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

{{Hint|see
[https://ose-workbench-platform.readthedocs.io/en/latest/ ose-workbench-platform] and [https://ose-3d-printer-workbench.readthedocs.io/en/latest/index.html# ose-3d-printer-workbench] for related work on ose documentation generation, git, and versioning}}

= Tuesday 30 June 2020 =

Creating a pop filter with an embroidery hoop for my microphone. The P's are now acceptable.

= Sunday 28 June 2020 =

Adding clips, recording voice for the Arduino/KiCAD tutorial with a new microphone. The microphone is good, but the P's are horrible. On pronunciation of a P, the recording clips every time. I need to have a pop filter.

= Saturday 27 June 2020 =

Working on the KiCAD/Arduino video tutorial. First making the notes for the minimal Arduino powered by an LED.

= Tuesday 23 June 2020 =

Meeting with Benedikt, Moritz, and Robin. We discussed several benefits and drawbacks of the Nextcloud, Gollum wiki, and the current OSE wiki. The current OSE wiki supports authentication and authorization. Authentication means that you can identify yourself, for example with a password. Authorization is slightly different; after having been authenticated, authorization defines a policy on who can do what. Traditional wiki's elevate the level of authorization automatically based on contributions. For example, a new user is not allowed to rename a page. However, after several contributions a new user is automatically authorized to do so.

Gollum supports anonymous contributions but appears to not have sophisticated ways to do authentication/authorization. In addition, to make a distributed infrastructure, it should be possible to fill the content of the Gollum wiki based on multiple git repositories. This may be possible with git submodules, but git modules are supposed to nest git repositories and remain fixed on a specific commit of a different repository. This is a bit different from what Gollum should support because you would want to host a specific branch and follow that branch. Perhaps this is possible by creating an automatic pull script.

With all this in mind, I concluded that I like my original idea:
* Move development of machines to git, for example github
* For each machine, have a dedicated git repository with
** licencse
** readme
** Makefile
** submodules for dependencies (for example the universal axis is a submodule of the 3d printer)
* The makefile generates documentation:
** A build manual
** A wiki page
** Images for the FreeCAD files

I'm going to experiment with this for a next meeting.

In the meantime user [[User:Groques|Groques]] has hinted to me that he is also working on versioning from a bit different perspective. We definitely have to talk about this.

After the meeting I have been experimenting with [https://pandoc.org/ Pandoc] from [https://orgmode.org/ Orgmode]. Orgmode is a file format supported by a 'mode' for [https://www.gnu.org/software/emacs/ Emacs], a widely used editor. It allows you to write TODO's, notes, presentations, academic papers in just normal text, similar to [https://www.markdownguide.org/ Markdown], but a bit more powerful, especially with the support from the editor. For example, Org files allow you to create tables and spreadsheets with column and row formula's, automatically computing values. It supports code blocks in many languages and these code blocks can be executed from the document and the code blocks can even interact with each other, even between different languages.

I documented the Nextcloud installation file in Org mode and with Pandoc I transformed it to the wiki format. Unfortunately, this wiki does not support code highlighting, for some reason, so I had to adjust the output slightly.

The result of the Org mode to wiki format translation is here: [[Install Nextcloud on Arch Linux]].

= Sunday 21 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Saturday 20 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Wednesday 10 June 2020 =

Meeting with Holger and Benedikt. Benedikt also invited Robin from OSE Germany and Moritz. We discussed alternative digital infrastructure setups including the Nextcloud instance that I created, creating a wiki powered by git, in the form of [https://github.com/gollum/gollum/wiki Gollum]. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-07-05T10:46:27Z

Pieter: /* Tuesday 23 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

{{Hint|see
[https://ose-workbench-platform.readthedocs.io/en/latest/ ose-workbench-platform] and [https://ose-3d-printer-workbench.readthedocs.io/en/latest/index.html# ose-3d-printer-workbench] for related work on ose documentation generation, git, and versioning}}

= Tuesday 23 June 2020 =

Meeting with Benedikt, Moritz, and Robin. We discussed several benefits and drawbacks of the Nextcloud, Gollum wiki, and the current OSE wiki. The current OSE wiki supports authentication and authorization. Authentication means that you can identify yourself, for example with a password. Authorization is slightly different; after having been authenticated, authorization defines a policy on who can do what. Traditional wiki's elevate the level of authorization automatically based on contributions. For example, a new user is not allowed to rename a page. However, after several contributions a new user is automatically authorized to do so.

Gollum supports anonymous contributions but appears to not have sophisticated ways to do authentication/authorization. In addition, to make a distributed infrastructure, it should be possible to fill the content of the Gollum wiki based on multiple git repositories. This may be possible with git submodules, but git modules are supposed to nest git repositories and remain fixed on a specific commit of a different repository. This is a bit different from what Gollum should support because you would want to host a specific branch and follow that branch. Perhaps this is possible by creating an automatic pull script.

With all this in mind, I concluded that I like my original idea:
* Move development of machines to git, for example github
* For each machine, have a dedicated git repository with
** licencse
** readme
** Makefile
** submodules for dependencies (for example the universal axis is a submodule of the 3d printer)
* The makefile generates documentation:
** A build manual
** A wiki page
** Images for the FreeCAD files

I'm going to experiment with this for a next meeting.

In the meantime user [[User:Groques|Groques]] has hinted to me that he is also working on versioning from a bit different perspective. We definitely have to talk about this.

After the meeting I have been experimenting with [https://pandoc.org/ Pandoc] from [https://orgmode.org/ Orgmode]. Orgmode is a file format supported by a 'mode' for [https://www.gnu.org/software/emacs/ Emacs], a widely used editor. It allows you to write TODO's, notes, presentations, academic papers in just normal text, similar to [https://www.markdownguide.org/ Markdown], but a bit more powerful, especially with the support from the editor. For example, Org files allow you to create tables and spreadsheets with column and row formula's, automatically computing values. It supports code blocks in many languages and these code blocks can be executed from the document and the code blocks can even interact with each other, even between different languages.

I documented the Nextcloud installation file in Org mode and with Pandoc I transformed it to the wiki format. Unfortunately, this wiki does not support code highlighting, for some reason, so I had to adjust the output slightly.

The result of the Org mode to wiki format translation is here: [[Install Nextcloud on Arch Linux]].

= Sunday 21 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Saturday 20 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Wednesday 10 June 2020 =

Meeting with Holger and Benedikt. Benedikt also invited Robin from OSE Germany and Moritz. We discussed alternative digital infrastructure setups including the Nextcloud instance that I created, creating a wiki powered by git, in the form of [https://github.com/gollum/gollum/wiki Gollum]. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-07-05T10:09:18Z

Pieter: /* Sunday 21 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

{{Hint|see
[https://ose-workbench-platform.readthedocs.io/en/latest/ ose-workbench-platform] and [https://ose-3d-printer-workbench.readthedocs.io/en/latest/index.html# ose-3d-printer-workbench] for related work on ose documentation generation, git, and versioning}}

= Sunday 21 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Saturday 20 June 2020 =

Add several clips for the KiCAD/Arduino video series.

= Wednesday 10 June 2020 =

Meeting with Holger and Benedikt. Benedikt also invited Robin from OSE Germany and Moritz. We discussed alternative digital infrastructure setups including the Nextcloud instance that I created, creating a wiki powered by git, in the form of [https://github.com/gollum/gollum/wiki Gollum]. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-07-05T10:06:34Z

Pieter: /* Sunday 7 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

{{Hint|see
[https://ose-workbench-platform.readthedocs.io/en/latest/ ose-workbench-platform] and [https://ose-3d-printer-workbench.readthedocs.io/en/latest/index.html# ose-3d-printer-workbench] for related work on ose documentation generation, git, and versioning}}

= Wednesday 10 June 2020 =

Meeting with Holger and Benedikt. Benedikt also invited Robin from OSE Germany and Moritz. We discussed alternative digital infrastructure setups including the Nextcloud instance that I created, creating a wiki powered by git, in the form of [https://github.com/gollum/gollum/wiki Gollum]. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-06-23T20:23:50Z

Pieter: /* Sunday 7 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described in [[Install Nextcloud on Arch Linux]].

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Install Nextcloud on Arch Linux

2020-06-23T20:23:21Z

Pieter: /* Introduction */

= Introduction =

This document describes how to set up Nextcloud on a virtual private server (VPS) hosted by a cloud service provider that provides images for Arch Linux. We assume there is a DNS record in place that points the address <code>cloud.mydomain.net</code> to the IP address provided by the cloud service provider. Note that this is not a hardened installation, it is merely used for experimentation. More configuration is required to harden the installation.

= Basic setup Arch Linux =

== Initial setup ==

Since the system comes preinstalled with Arch Linux on it, the first thing to do is to update the system:

<pre lang="bash">pacman -Syu

reboot

pacman -S base base-devel
</pre>
== Add an administration user ==

We add a day-to-day administrator account:

<pre lang="bash">useradd -m -g users -s /bin/bash admin
passwd admin
</pre>
Make sure that <code>pacman</code> can be executed as user <code>admin</code>:

<pre lang="bash">visudo
</pre>
And add the following:

<pre lang="bash">admin ALL=(ALL) NOPASSWD: /usr/bin/pacman
</pre>
== Create a swap partition ==

The swap partition has already been activated, so there is nothing to do.

== Configure the language and locales ==

In file <code>/etc/locale.gen</code>:

<pre lang="bash">en_US.UTF-8 UTF-8
</pre>
Then execute:

<pre lang="bash">locale-gen

echo LANG=en_US.UTF-8 > /etc/locale.conf
export LANG=en_US.UTF-8
</pre>
Add the correct time zone, for example:

<pre class="commonlisp">ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
</pre>
== Time configuration ==

Since Arch sits in a virtual machine, we assume that the time is always correct.

== Random number generation ==

Random number generation is important for security, so we install the following tools:

<pre lang="bash">pacman -S rng-tools

systemctl start rngd
systemctl enable rngd
</pre>
To check the level of entropy we can do:

<pre lang="bash">cat /proc/sys/kernel/random/entropy_available
</pre>
Since it runs on a virtual machine, we are not really sure how representative the entropy is.

We can also run the following tests which should have very few failures:

<pre lang="bash">cat /dev/random | rngtest -c 1000
cat /dev/urandom | rngtest -c 1000
</pre>
The <code>rng-tools</code> service is preferred over <code>haveged</code>.

== Setting the hostname ==

Assuming we have a hostname <code>mydomainname.net</code> that points to our server's IP address:

In <code>/etc/hostname</code>:

<pre lang="bash">cloud.mydomainname.net
</pre>
In <code>/etc/hosts</code>:

<pre lang="bash">127.0.1.1 cloud.mydomainname.net
</pre>
After a reboot, we can check whether everything is set with the command <code>hostname -f</code>.

== Setting up the network ==

The network has been set up fine by the cloud provider.

== Setting up the firewall ==

We use <code>iptables</code> to set up the firewall. A chain is a set of rules. The chain INPUT is predefined for packets that enter the system.

First we set the policy for chain INPUT to target ACCEPT:

<pre lang="bash">iptables -P INPUT ACCEPT
ip6tables -P INPUT ACCEPT
</pre>
We then flush all the chains:

<pre lang="bash">iptables -F
ip6tables -F
</pre>
A table in this context is a packet matching table. There are five predefined tables. The default table ''filter'', the tables ''nat'', ''mangle'', ''raw'', and ''security''. We flush the table ''nat'':

<pre lang="bash">iptables -t nat -F
ip6tables -t nat -F
</pre>
We then delete all the user-defined chains:

<pre lang="bash">iptables -X
ip6tables -X
</pre>
We then set the policy to drop every packet that enters the system (make sure you are logged in via a video display and not SSH):

<pre lang="bash">iptables -P INPUT DROP
ip6tables -P INPUT DROP
</pre>
We append to chain INPUT on the loopback interface <code>lo</code> to jump to target ACCEPT. This is important for applications that use local servers.

<pre lang="bash">iptables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
</pre>
We then append to chain INPUT on interface <code>ens3</code> a rule to accept connections with states ESTABLISHED and RELATED:

<pre lang="bash">iptables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
</pre>
We then make sure that incomming TCP connections are SYN packets to prevent SYN flooding:

<pre lang="bash">iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
ip6tables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
</pre>
We also drop packets with incoming fragments. This is only for IPv4:

<pre lang="bash">iptables -A INPUT -f -j DROP
</pre>
We also drop bogons:

<pre lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
</pre>
We also reject malformed NULL packets:

<pre lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
</pre>
We can then store the firewall rules with the following commands:

<pre lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</pre>
To make the changes permanent, we can enable and start the Systemd service:

<pre lang="bash">systemctl start iptables.service
systemctl enable iptables.service
systemctl status iptables.service

systemctl start ip6tables.service
systemctl enable ip6tables.service
systemctl status ip6tables.service
</pre>
== Fail2ban ==

The service fail2ban is a service for detecting login attempts and blocking it.

We install it with:

<pre lang="bash">pacman -S fail2ban
</pre>
Using <code>systemd</code> we can sandbox the fail2ban service with capabilities. To do so, we create a new file <code>/etc/systemd/system/fail2ban.service.d/capabilities.conf</code> with the following contents:

<pre lang="bash">[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=read-only
ProtectSystem=strict
NoNewPrivileges=yes
ReadWritePaths=-/var/run/fail2ban
ReadWritePaths=-/var/lib/fail2ban
ReadWritePaths=-/var/log/fail2ban
ReadWritePaths=-/var/spool/postfix/maildrop
ReadWritePaths=-/run/xtables.lock
CapabilityBoundingSet=CAP_AUDIT_READ CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
</pre>
Create configuration file <code>/etc/fail2ban/fail2ban.local</code> with the correct logtarget path:

<pre lang="bash">[Definition]
logtarget = /var/log/fail2ban/fail2ban.log
</pre>
Create the <code>/var/log/fail2ban/</code> directory as root.

We have to set up paths for Arch Linux in a <code>jail.local</code> file:

<pre lang="bash">[INCLUDES]
before = paths-arch.conf
</pre>
== Yay ==

With yay, we can keep also the AUR packages up to date.

<pre lang="bash">git clone https://aur.archlinux.org/yay.git
tar xvzf yay.tar.gz
cd yay
makepkg -s
pacman -U yay*.pkg.tar.xz
</pre>
= SSH access =

== Configuration ==

The first service we would like to set up is SSH. We first configure the SSH daemon itself in file <code>/etc/ssh/sshd_config</code>:

<pre lang="bash">PermitRootLogin no
TCPKeepAlive no
ClientAliveInterval 60
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
</pre>
We then restart the daemon:

<pre lang="bash">systemctl restart sshd
</pre>
== The firewall ==

We have to open port 22 for SSH in our firewall:

<pre lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
</pre>
<pre lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</pre>
== Fail2ban ==

We add the following jails in <code>/etc/fail2ban/jail.d/</code>:

In <code>sshd.conf</code>:

<pre lang="bash">[sshd]
enabled = true
</pre>

= Installing Nextcloud =

The version to install is 19.0.0. We are going to install it on top of <code>nginx</code> and <code>MariaDB</code>.

== MariaDB ==

As a first step, we are going to install MariaDB with package <code>mariadb</code>. Before we start the service, we run:

<pre lang="bash">mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
systemctl start mariadb</pre>
Then add the database (substitute the password with a proper one):

<pre lang="sql">CREATE DATABASE nextcloud DEFAULT CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;</pre>
== PHP ==

Install PHP with package <code>php</code>. We need to do additional configuration, in <code>/etc/php/php.ini</code>:

<pre lang="bash">date.timezone = Europe/Amsterdam
memory_limit = 512M</pre>
For PHP we need to install the following modules:

{|
! module
! package
! comments
|-
| ctype
| php
|
|-
| curl
| php
|
|-
| dom
| php
|
|-
| GD
| php-gd
| enable in php.ini
|-
| iconv
| php
| enable in php.ini
|-
| json
| php
|
|-
| libxml
| php
|
|-
| mbstring
| php
|
|-
| openssl
| php
|
|-
| posix
| php
|
|-
| session
| php
|
|-
| SimpleXML
| php
|
|-
| xmlreader
| php
|
|-
| xmlwriter
| php
|
|-
| zip
| php
|
|-
| zlib
| php
|
|-
| pdomysql
| php
| enable in php.ini
|-
| mysqli
| php
| enable in php.ini
|-
| fileinfo
| php
|
|-
| bz2
| php
| enable in php.ini
|-
| intl
| php-intl
| enable in php.ini
|-
| bcmath
| php
| enable in php.ini
|-
| gmp
| php
| enable in php.ini
|-
| imagick
| php-imagick
| enable in conf.d/imagick.ini
|}

For further support for <code>imagick</code>, it is wise to install the following packages:

<pre lang="bash">pacman -S ghostscript librsvg libwmf ocl-icd openexr openjpeg2 pango</pre>
We enable OPCache in <code>php.ini</code>:

<pre lang="bash">zend_extension=opcache</pre>
And we set the following options:

<pre lang="bash">opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1</pre>
We enable APCu by installing <code>php-apcu</code> and enabling it in <code>/etc/php/conf.d/apcu.ini</code>:

<pre lang="bash">extension=apcu.so</pre>
== Nginx ==

We install <code>nginx</code> and set it up to obtain certificates by enabling the service, and open port 80:

<pre lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
systemctl enable nginx
systemctl start nginx</pre>
We get a message that the <code>max_types_hash_size</code> is not enough. In <code>/etc/nginx/nginx.conf</code> add in the <code>http</code> block:

<pre lang="bash">types_hash_max_size 4096;</pre>
We are now ready to install certificates.

=== Let's Encrypt certificates ===

Install the following packages to acquire certificates: <code>certbot</code>, <code>certbot-nginx</code>.

Then run:

<pre lang="bash">certbot --nginx</pre>
We fill in:

{|
| email address
| <your email address>
|-
| terms
| agree
|-
| share info
| no
|-
| domain
| cloud.mydomain.net
|}

It aquires the certificates but cannot find the server block for this domain.

=== PHP CGI ===

Install package <code>php-fpm</code> and in the configuration file <code>/etc/php/php-fpm.d/www.conf</code> uncomment <code>env[PATH]</code>. Also set up <code>env[TMP]</code> in <code>/etc/php/php-fpm.d/www.conf</code> and make sure the directory is writable for the Nginx user.

We also set the following values in <code>/etc/php/php-fpm.d/www.conf</code>, taken from the documentation and all values divided by 2.

<pre lang="bash">pm.max_children = 60;
pm.start_servers = 6;
pm.min_spare_servers = 3;
pm.max_spare_servers = 9;</pre>
<pre lang="bash">systemctl start php-fpm
systemctl enable php-fpm</pre>
== Nextcloud ==

<pre lang="bash">pacman -S nextcloud</pre>
We install the following pacman hook in <code>/etc/pacman.d/hooks/nextcloud.hook</code>:

<pre lang="bash">[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = nextcloud
Target = nextcloud-app-*

[Action]
Description = Update Nextcloud installation
When = PostTransaction
Exec = /usr/bin/runuser -u http -- /usr/bin/php /usr/share/webapps/nextcloud/occ upgrade</pre>
Create a server block in the <code>nginx.conf</code>:

<pre lang="bash">upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php-fpm/php-fpm.sock;
}

server {
listen 80;
listen [::]:80;
server_name cloud.mydomain.net;
# enforce https
return 301 https://$server_name:443$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name cloud.mydomain.net;

ssl_certificate /etc/letsencrypt/live/cloud.mydomain.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.mydomain.net/privkey.pem;

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

# Path to the root of your installation
root /usr/share/webapps/nextcloud;

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}

# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;

# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;

location / {
rewrite ^ /index.php;
}

location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
deny all;
}
location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}

location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy)\.php(?:$|\/) {
fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
# Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
# Enable pretty urls
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}

location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
try_files $uri/ =404;
index index.php;
}

# Adding the cache control header for js, css and map files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Optional: Don't log access to assets
access_log off;
}

location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$ {
try_files $uri /index.php$request_uri;
# Optional: Don't log access to other assets
access_log off;
}
}</pre>
We have to create a data directory for Nextcloud:

<pre lang="bash">mkdir /var/nextcloud
chown http:http /var/nextcloud
chmod 750 /var/nextcloud</pre>
We also have to change permissions for the apps directories:

<pre lang="bash">mkdir -p /usr/share/webapps/nextcloud/data
chown -R http:http /usr/share/webapps/nextcloud/{apps,data}
chmod 750 /usr/share/webapps/nextcloud/{apps,data}</pre>
We have to give <code>php-fpm</code> permissions. We do this with the following command:

<pre lang="bash">systemctl edit php-fpm.service</pre>
This will save the contents in <code>/etc/systemd/system/php-fpm.service.d/override.conf</code>.

The contents:

<pre lang="bash">[Service]
ReadWritePaths = /usr/share/webapps/nextcloud/apps
ReadWritePaths = /usr/share/webapps/nextcloud/data
ReadWritePaths = /etc/webapps/nextcloud/config

# Replace the following path with the Nextcloud data directory
ReadWritePaths = /var/nextcloud</pre>
We then do:

<pre lang="bash">systemctl restart php-fpm</pre>
We can then open the firewall on port 80 and 443:

<pre lang="bash">systemctl stop fail2ban
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
systemctl start fail2ban</pre>
== Postinstall ==

It turns out that the cache was not enabled. We do that by adding the following key to <code>/etc/webapps/nextcloud/config/config.php</code>:

<pre lang="php">'memcache.local' => '\OC\Memcache\APCu',</pre>
Install the following apps:

* talk
* deck
* notes

== Maintenance ==

The services that are run are:

* mariadb
* nginx
* php-fpm

Pieter log

2020-06-23T20:22:24Z

Pieter: /* Sunday 7 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS. The installation process has been described [[Install Nextcloud on Arch Linux]]

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Install Nextcloud on Arch Linux

2020-06-23T20:21:08Z

Pieter: Change source tags to pre

= Introduction =

This document describes how to set up Nextcloud on a virtual private server (VPS) hosted by a cloud service provider that provides images for Arch Linux. We assume there is a DNS record in place that points the address <code>cloud.mydomain.net</code> to the IP address provided by the cloud service provider.

= Basic setup Arch Linux =

== Initial setup ==

Since the system comes preinstalled with Arch Linux on it, the first thing to do is to update the system:

<pre lang="bash">pacman -Syu

reboot

pacman -S base base-devel
</pre>
== Add an administration user ==

We add a day-to-day administrator account:

<pre lang="bash">useradd -m -g users -s /bin/bash admin
passwd admin
</pre>
Make sure that <code>pacman</code> can be executed as user <code>admin</code>:

<pre lang="bash">visudo
</pre>
And add the following:

<pre lang="bash">admin ALL=(ALL) NOPASSWD: /usr/bin/pacman
</pre>
== Create a swap partition ==

The swap partition has already been activated, so there is nothing to do.

== Configure the language and locales ==

In file <code>/etc/locale.gen</code>:

<pre lang="bash">en_US.UTF-8 UTF-8
</pre>
Then execute:

<pre lang="bash">locale-gen

echo LANG=en_US.UTF-8 > /etc/locale.conf
export LANG=en_US.UTF-8
</pre>
Add the correct time zone, for example:

<pre class="commonlisp">ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
</pre>
== Time configuration ==

Since Arch sits in a virtual machine, we assume that the time is always correct.

== Random number generation ==

Random number generation is important for security, so we install the following tools:

<pre lang="bash">pacman -S rng-tools

systemctl start rngd
systemctl enable rngd
</pre>
To check the level of entropy we can do:

<pre lang="bash">cat /proc/sys/kernel/random/entropy_available
</pre>
Since it runs on a virtual machine, we are not really sure how representative the entropy is.

We can also run the following tests which should have very few failures:

<pre lang="bash">cat /dev/random | rngtest -c 1000
cat /dev/urandom | rngtest -c 1000
</pre>
The <code>rng-tools</code> service is preferred over <code>haveged</code>.

== Setting the hostname ==

Assuming we have a hostname <code>mydomainname.net</code> that points to our server's IP address:

In <code>/etc/hostname</code>:

<pre lang="bash">cloud.mydomainname.net
</pre>
In <code>/etc/hosts</code>:

<pre lang="bash">127.0.1.1 cloud.mydomainname.net
</pre>
After a reboot, we can check whether everything is set with the command <code>hostname -f</code>.

== Setting up the network ==

The network has been set up fine by the cloud provider.

== Setting up the firewall ==

We use <code>iptables</code> to set up the firewall. A chain is a set of rules. The chain INPUT is predefined for packets that enter the system.

First we set the policy for chain INPUT to target ACCEPT:

<pre lang="bash">iptables -P INPUT ACCEPT
ip6tables -P INPUT ACCEPT
</pre>
We then flush all the chains:

<pre lang="bash">iptables -F
ip6tables -F
</pre>
A table in this context is a packet matching table. There are five predefined tables. The default table ''filter'', the tables ''nat'', ''mangle'', ''raw'', and ''security''. We flush the table ''nat'':

<pre lang="bash">iptables -t nat -F
ip6tables -t nat -F
</pre>
We then delete all the user-defined chains:

<pre lang="bash">iptables -X
ip6tables -X
</pre>
We then set the policy to drop every packet that enters the system (make sure you are logged in via a video display and not SSH):

<pre lang="bash">iptables -P INPUT DROP
ip6tables -P INPUT DROP
</pre>
We append to chain INPUT on the loopback interface <code>lo</code> to jump to target ACCEPT. This is important for applications that use local servers.

<pre lang="bash">iptables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
</pre>
We then append to chain INPUT on interface <code>ens3</code> a rule to accept connections with states ESTABLISHED and RELATED:

<pre lang="bash">iptables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
</pre>
We then make sure that incomming TCP connections are SYN packets to prevent SYN flooding:

<pre lang="bash">iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
ip6tables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
</pre>
We also drop packets with incoming fragments. This is only for IPv4:

<pre lang="bash">iptables -A INPUT -f -j DROP
</pre>
We also drop bogons:

<pre lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
</pre>
We also reject malformed NULL packets:

<pre lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
</pre>
We can then store the firewall rules with the following commands:

<pre lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</pre>
To make the changes permanent, we can enable and start the Systemd service:

<pre lang="bash">systemctl start iptables.service
systemctl enable iptables.service
systemctl status iptables.service

systemctl start ip6tables.service
systemctl enable ip6tables.service
systemctl status ip6tables.service
</pre>
== Fail2ban ==

The service fail2ban is a service for detecting login attempts and blocking it.

We install it with:

<pre lang="bash">pacman -S fail2ban
</pre>
Using <code>systemd</code> we can sandbox the fail2ban service with capabilities. To do so, we create a new file <code>/etc/systemd/system/fail2ban.service.d/capabilities.conf</code> with the following contents:

<pre lang="bash">[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=read-only
ProtectSystem=strict
NoNewPrivileges=yes
ReadWritePaths=-/var/run/fail2ban
ReadWritePaths=-/var/lib/fail2ban
ReadWritePaths=-/var/log/fail2ban
ReadWritePaths=-/var/spool/postfix/maildrop
ReadWritePaths=-/run/xtables.lock
CapabilityBoundingSet=CAP_AUDIT_READ CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
</pre>
Create configuration file <code>/etc/fail2ban/fail2ban.local</code> with the correct logtarget path:

<pre lang="bash">[Definition]
logtarget = /var/log/fail2ban/fail2ban.log
</pre>
Create the <code>/var/log/fail2ban/</code> directory as root.

We have to set up paths for Arch Linux in a <code>jail.local</code> file:

<pre lang="bash">[INCLUDES]
before = paths-arch.conf
</pre>
== Yay ==

With yay, we can keep also the AUR packages up to date.

<pre lang="bash">git clone https://aur.archlinux.org/yay.git
tar xvzf yay.tar.gz
cd yay
makepkg -s
pacman -U yay*.pkg.tar.xz
</pre>
= SSH access =

== Configuration ==

The first service we would like to set up is SSH. We first configure the SSH daemon itself in file <code>/etc/ssh/sshd_config</code>:

<pre lang="bash">PermitRootLogin no
TCPKeepAlive no
ClientAliveInterval 60
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
</pre>
We then restart the daemon:

<pre lang="bash">systemctl restart sshd
</pre>
== The firewall ==

We have to open port 22 for SSH in our firewall:

<pre lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
</pre>
<pre lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</pre>
== Fail2ban ==

We add the following jails in <code>/etc/fail2ban/jail.d/</code>:

In <code>sshd.conf</code>:

<pre lang="bash">[sshd]
enabled = true
</pre>

= Installing Nextcloud =

The version to install is 19.0.0. We are going to install it on top of <code>nginx</code> and <code>MariaDB</code>.

== MariaDB ==

As a first step, we are going to install MariaDB with package <code>mariadb</code>. Before we start the service, we run:

<pre lang="bash">mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
systemctl start mariadb</pre>
Then add the database (substitute the password with a proper one):

<pre lang="sql">CREATE DATABASE nextcloud DEFAULT CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;</pre>
== PHP ==

Install PHP with package <code>php</code>. We need to do additional configuration, in <code>/etc/php/php.ini</code>:

<pre lang="bash">date.timezone = Europe/Amsterdam
memory_limit = 512M</pre>
For PHP we need to install the following modules:

{|
! module
! package
! comments
|-
| ctype
| php
|
|-
| curl
| php
|
|-
| dom
| php
|
|-
| GD
| php-gd
| enable in php.ini
|-
| iconv
| php
| enable in php.ini
|-
| json
| php
|
|-
| libxml
| php
|
|-
| mbstring
| php
|
|-
| openssl
| php
|
|-
| posix
| php
|
|-
| session
| php
|
|-
| SimpleXML
| php
|
|-
| xmlreader
| php
|
|-
| xmlwriter
| php
|
|-
| zip
| php
|
|-
| zlib
| php
|
|-
| pdomysql
| php
| enable in php.ini
|-
| mysqli
| php
| enable in php.ini
|-
| fileinfo
| php
|
|-
| bz2
| php
| enable in php.ini
|-
| intl
| php-intl
| enable in php.ini
|-
| bcmath
| php
| enable in php.ini
|-
| gmp
| php
| enable in php.ini
|-
| imagick
| php-imagick
| enable in conf.d/imagick.ini
|}

For further support for <code>imagick</code>, it is wise to install the following packages:

<pre lang="bash">pacman -S ghostscript librsvg libwmf ocl-icd openexr openjpeg2 pango</pre>
We enable OPCache in <code>php.ini</code>:

<pre lang="bash">zend_extension=opcache</pre>
And we set the following options:

<pre lang="bash">opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1</pre>
We enable APCu by installing <code>php-apcu</code> and enabling it in <code>/etc/php/conf.d/apcu.ini</code>:

<pre lang="bash">extension=apcu.so</pre>
== Nginx ==

We install <code>nginx</code> and set it up to obtain certificates by enabling the service, and open port 80:

<pre lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
systemctl enable nginx
systemctl start nginx</pre>
We get a message that the <code>max_types_hash_size</code> is not enough. In <code>/etc/nginx/nginx.conf</code> add in the <code>http</code> block:

<pre lang="bash">types_hash_max_size 4096;</pre>
We are now ready to install certificates.

=== Let's Encrypt certificates ===

Install the following packages to acquire certificates: <code>certbot</code>, <code>certbot-nginx</code>.

Then run:

<pre lang="bash">certbot --nginx</pre>
We fill in:

{|
| email address
| <your email address>
|-
| terms
| agree
|-
| share info
| no
|-
| domain
| cloud.mydomain.net
|}

It aquires the certificates but cannot find the server block for this domain.

=== PHP CGI ===

Install package <code>php-fpm</code> and in the configuration file <code>/etc/php/php-fpm.d/www.conf</code> uncomment <code>env[PATH]</code>. Also set up <code>env[TMP]</code> in <code>/etc/php/php-fpm.d/www.conf</code> and make sure the directory is writable for the Nginx user.

We also set the following values in <code>/etc/php/php-fpm.d/www.conf</code>, taken from the documentation and all values divided by 2.

<pre lang="bash">pm.max_children = 60;
pm.start_servers = 6;
pm.min_spare_servers = 3;
pm.max_spare_servers = 9;</pre>
<pre lang="bash">systemctl start php-fpm
systemctl enable php-fpm</pre>
== Nextcloud ==

<pre lang="bash">pacman -S nextcloud</pre>
We install the following pacman hook in <code>/etc/pacman.d/hooks/nextcloud.hook</code>:

<pre lang="bash">[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = nextcloud
Target = nextcloud-app-*

[Action]
Description = Update Nextcloud installation
When = PostTransaction
Exec = /usr/bin/runuser -u http -- /usr/bin/php /usr/share/webapps/nextcloud/occ upgrade</pre>
Create a server block in the <code>nginx.conf</code>:

<pre lang="bash">upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php-fpm/php-fpm.sock;
}

server {
listen 80;
listen [::]:80;
server_name cloud.mydomain.net;
# enforce https
return 301 https://$server_name:443$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name cloud.mydomain.net;

ssl_certificate /etc/letsencrypt/live/cloud.mydomain.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.mydomain.net/privkey.pem;

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

# Path to the root of your installation
root /usr/share/webapps/nextcloud;

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}

# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;

# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;

location / {
rewrite ^ /index.php;
}

location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
deny all;
}
location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}

location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy)\.php(?:$|\/) {
fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
# Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
# Enable pretty urls
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}

location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
try_files $uri/ =404;
index index.php;
}

# Adding the cache control header for js, css and map files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Optional: Don't log access to assets
access_log off;
}

location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$ {
try_files $uri /index.php$request_uri;
# Optional: Don't log access to other assets
access_log off;
}
}</pre>
We have to create a data directory for Nextcloud:

<pre lang="bash">mkdir /var/nextcloud
chown http:http /var/nextcloud
chmod 750 /var/nextcloud</pre>
We also have to change permissions for the apps directories:

<pre lang="bash">mkdir -p /usr/share/webapps/nextcloud/data
chown -R http:http /usr/share/webapps/nextcloud/{apps,data}
chmod 750 /usr/share/webapps/nextcloud/{apps,data}</pre>
We have to give <code>php-fpm</code> permissions. We do this with the following command:

<pre lang="bash">systemctl edit php-fpm.service</pre>
This will save the contents in <code>/etc/systemd/system/php-fpm.service.d/override.conf</code>.

The contents:

<pre lang="bash">[Service]
ReadWritePaths = /usr/share/webapps/nextcloud/apps
ReadWritePaths = /usr/share/webapps/nextcloud/data
ReadWritePaths = /etc/webapps/nextcloud/config

# Replace the following path with the Nextcloud data directory
ReadWritePaths = /var/nextcloud</pre>
We then do:

<pre lang="bash">systemctl restart php-fpm</pre>
We can then open the firewall on port 80 and 443:

<pre lang="bash">systemctl stop fail2ban
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
systemctl start fail2ban</pre>
== Postinstall ==

It turns out that the cache was not enabled. We do that by adding the following key to <code>/etc/webapps/nextcloud/config/config.php</code>:

<pre lang="php">'memcache.local' => '\OC\Memcache\APCu',</pre>
Install the following apps:

* talk
* deck
* notes

== Maintenance ==

The services that are run are:

* mariadb
* nginx
* php-fpm

Install Nextcloud on Arch Linux

2020-06-23T20:17:38Z

Pieter: Add the Nextcloud installation part

= Comment =

For some reason the <source> tags don't work, will fix it later.

= Introduction =

This document describes how to set up Nextcloud on a virtual private server (VPS) hosted by a cloud service provider that provides images for Arch Linux. We assume there is a DNS record in place that points the address <code>cloud.mydomain.net</code> to the IP address provided by the cloud service provider.

= Basic setup Arch Linux =

== Initial setup ==

Since the system comes preinstalled with Arch Linux on it, the first thing to do is to update the system:

<source lang="bash">pacman -Syu

reboot

pacman -S base base-devel
</source>
== Add an administration user ==

We add a day-to-day administrator account:

<source lang="bash">useradd -m -g users -s /bin/bash admin
passwd admin
</source>
Make sure that <code>pacman</code> can be executed as user <code>admin</code>:

<source lang="bash">visudo
</source>
And add the following:

<source lang="bash">admin ALL=(ALL) NOPASSWD: /usr/bin/pacman
</source>
== Create a swap partition ==

The swap partition has already been activated, so there is nothing to do.

== Configure the language and locales ==

In file <code>/etc/locale.gen</code>:

<source lang="bash">en_US.UTF-8 UTF-8
</source>
Then execute:

<source lang="bash">locale-gen

echo LANG=en_US.UTF-8 > /etc/locale.conf
export LANG=en_US.UTF-8
</source>
Add the correct time zone, for example:

<pre class="commonlisp">ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
</pre>
== Time configuration ==

Since Arch sits in a virtual machine, we assume that the time is always correct.

== Random number generation ==

Random number generation is important for security, so we install the following tools:

<source lang="bash">pacman -S rng-tools

systemctl start rngd
systemctl enable rngd
</source>
To check the level of entropy we can do:

<source lang="bash">cat /proc/sys/kernel/random/entropy_available
</source>
Since it runs on a virtual machine, we are not really sure how representative the entropy is.

We can also run the following tests which should have very few failures:

<source lang="bash">cat /dev/random | rngtest -c 1000
cat /dev/urandom | rngtest -c 1000
</source>
The <code>rng-tools</code> service is preferred over <code>haveged</code>.

== Setting the hostname ==

Assuming we have a hostname <code>mydomainname.net</code> that points to our server's IP address:

In <code>/etc/hostname</code>:

<source lang="bash">cloud.mydomainname.net
</source>
In <code>/etc/hosts</code>:

<source lang="bash">127.0.1.1 cloud.mydomainname.net
</source>
After a reboot, we can check whether everything is set with the command <code>hostname -f</code>.

== Setting up the network ==

The network has been set up fine by the cloud provider.

== Setting up the firewall ==

We use <code>iptables</code> to set up the firewall. A chain is a set of rules. The chain INPUT is predefined for packets that enter the system.

First we set the policy for chain INPUT to target ACCEPT:

<source lang="bash">iptables -P INPUT ACCEPT
ip6tables -P INPUT ACCEPT
</source>
We then flush all the chains:

<source lang="bash">iptables -F
ip6tables -F
</source>
A table in this context is a packet matching table. There are five predefined tables. The default table ''filter'', the tables ''nat'', ''mangle'', ''raw'', and ''security''. We flush the table ''nat'':

<source lang="bash">iptables -t nat -F
ip6tables -t nat -F
</source>
We then delete all the user-defined chains:

<source lang="bash">iptables -X
ip6tables -X
</source>
We then set the policy to drop every packet that enters the system (make sure you are logged in via a video display and not SSH):

<source lang="bash">iptables -P INPUT DROP
ip6tables -P INPUT DROP
</source>
We append to chain INPUT on the loopback interface <code>lo</code> to jump to target ACCEPT. This is important for applications that use local servers.

<source lang="bash">iptables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
</source>
We then append to chain INPUT on interface <code>ens3</code> a rule to accept connections with states ESTABLISHED and RELATED:

<source lang="bash">iptables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
</source>
We then make sure that incomming TCP connections are SYN packets to prevent SYN flooding:

<source lang="bash">iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
ip6tables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
</source>
We also drop packets with incoming fragments. This is only for IPv4:

<source lang="bash">iptables -A INPUT -f -j DROP
</source>
We also drop bogons:

<source lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
</source>
We also reject malformed NULL packets:

<source lang="bash">iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
ip6tables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
</source>
We can then store the firewall rules with the following commands:

<source lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</source>
To make the changes permanent, we can enable and start the Systemd service:

<source lang="bash">systemctl start iptables.service
systemctl enable iptables.service
systemctl status iptables.service

systemctl start ip6tables.service
systemctl enable ip6tables.service
systemctl status ip6tables.service
</source>
== Fail2ban ==

The service fail2ban is a service for detecting login attempts and blocking it.

We install it with:

<source lang="bash">pacman -S fail2ban
</source>
Using <code>systemd</code> we can sandbox the fail2ban service with capabilities. To do so, we create a new file <code>/etc/systemd/system/fail2ban.service.d/capabilities.conf</code> with the following contents:

<source lang="bash">[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=read-only
ProtectSystem=strict
NoNewPrivileges=yes
ReadWritePaths=-/var/run/fail2ban
ReadWritePaths=-/var/lib/fail2ban
ReadWritePaths=-/var/log/fail2ban
ReadWritePaths=-/var/spool/postfix/maildrop
ReadWritePaths=-/run/xtables.lock
CapabilityBoundingSet=CAP_AUDIT_READ CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
</source>
Create configuration file <code>/etc/fail2ban/fail2ban.local</code> with the correct logtarget path:

<source lang="bash">[Definition]
logtarget = /var/log/fail2ban/fail2ban.log
</source>
Create the <code>/var/log/fail2ban/</code> directory as root.

We have to set up paths for Arch Linux in a <code>jail.local</code> file:

<source lang="bash">[INCLUDES]
before = paths-arch.conf
</source>
== Yay ==

With yay, we can keep also the AUR packages up to date.

<source lang="bash">git clone https://aur.archlinux.org/yay.git
tar xvzf yay.tar.gz
cd yay
makepkg -s
pacman -U yay*.pkg.tar.xz
</source>
= SSH access =

== Configuration ==

The first service we would like to set up is SSH. We first configure the SSH daemon itself in file <code>/etc/ssh/sshd_config</code>:

<source lang="bash">PermitRootLogin no
TCPKeepAlive no
ClientAliveInterval 60
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
</source>
We then restart the daemon:

<source lang="bash">systemctl restart sshd
</source>
== The firewall ==

We have to open port 22 for SSH in our firewall:

<source lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
</source>
<source lang="bash">iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
</source>
== Fail2ban ==

We add the following jails in <code>/etc/fail2ban/jail.d/</code>:

In <code>sshd.conf</code>:

<source lang="bash">[sshd]
enabled = true
</source>

= Installing Nextcloud =

The version to install is 19.0.0. We are going to install it on top of <code>nginx</code> and <code>MariaDB</code>.

== MariaDB ==

As a first step, we are going to install MariaDB with package <code>mariadb</code>. Before we start the service, we run:

<source lang="bash">mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
systemctl start mariadb</source>
Then add the database (substitute the password with a proper one):

<source lang="sql">CREATE DATABASE nextcloud DEFAULT CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;</source>
== PHP ==

Install PHP with package <code>php</code>. We need to do additional configuration, in <code>/etc/php/php.ini</code>:

<source lang="bash">date.timezone = Europe/Amsterdam
memory_limit = 512M</source>
For PHP we need to install the following modules:

{|
! module
! package
! comments
|-
| ctype
| php
|
|-
| curl
| php
|
|-
| dom
| php
|
|-
| GD
| php-gd
| enable in php.ini
|-
| iconv
| php
| enable in php.ini
|-
| json
| php
|
|-
| libxml
| php
|
|-
| mbstring
| php
|
|-
| openssl
| php
|
|-
| posix
| php
|
|-
| session
| php
|
|-
| SimpleXML
| php
|
|-
| xmlreader
| php
|
|-
| xmlwriter
| php
|
|-
| zip
| php
|
|-
| zlib
| php
|
|-
| pdomysql
| php
| enable in php.ini
|-
| mysqli
| php
| enable in php.ini
|-
| fileinfo
| php
|
|-
| bz2
| php
| enable in php.ini
|-
| intl
| php-intl
| enable in php.ini
|-
| bcmath
| php
| enable in php.ini
|-
| gmp
| php
| enable in php.ini
|-
| imagick
| php-imagick
| enable in conf.d/imagick.ini
|}

For further support for <code>imagick</code>, it is wise to install the following packages:

<source lang="bash">pacman -S ghostscript librsvg libwmf ocl-icd openexr openjpeg2 pango</source>
We enable OPCache in <code>php.ini</code>:

<source lang="bash">zend_extension=opcache</source>
And we set the following options:

<source lang="bash">opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1</source>
We enable APCu by installing <code>php-apcu</code> and enabling it in <code>/etc/php/conf.d/apcu.ini</code>:

<source lang="bash">extension=apcu.so</source>
== Nginx ==

We install <code>nginx</code> and set it up to obtain certificates by enabling the service, and open port 80:

<source lang="bash">iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
systemctl enable nginx
systemctl start nginx</source>
We get a message that the <code>max_types_hash_size</code> is not enough. In <code>/etc/nginx/nginx.conf</code> add in the <code>http</code> block:

<source lang="bash">types_hash_max_size 4096;</source>
We are now ready to install certificates.

=== Let's Encrypt certificates ===

Install the following packages to acquire certificates: <code>certbot</code>, <code>certbot-nginx</code>.

Then run:

<source lang="bash">certbot --nginx</source>
We fill in:

{|
| email address
| <your email address>
|-
| terms
| agree
|-
| share info
| no
|-
| domain
| cloud.mydomain.net
|}

It aquires the certificates but cannot find the server block for this domain.

=== PHP CGI ===

Install package <code>php-fpm</code> and in the configuration file <code>/etc/php/php-fpm.d/www.conf</code> uncomment <code>env[PATH]</code>. Also set up <code>env[TMP]</code> in <code>/etc/php/php-fpm.d/www.conf</code> and make sure the directory is writable for the Nginx user.

We also set the following values in <code>/etc/php/php-fpm.d/www.conf</code>, taken from the documentation and all values divided by 2.

<source lang="bash">pm.max_children = 60;
pm.start_servers = 6;
pm.min_spare_servers = 3;
pm.max_spare_servers = 9;</source>
<source lang="bash">systemctl start php-fpm
systemctl enable php-fpm</source>
== Nextcloud ==

<source lang="bash">pacman -S nextcloud</source>
We install the following pacman hook in <code>/etc/pacman.d/hooks/nextcloud.hook</code>:

<source lang="bash">[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = nextcloud
Target = nextcloud-app-*

[Action]
Description = Update Nextcloud installation
When = PostTransaction
Exec = /usr/bin/runuser -u http -- /usr/bin/php /usr/share/webapps/nextcloud/occ upgrade</source>
Create a server block in the <code>nginx.conf</code>:

<source lang="bash">upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php-fpm/php-fpm.sock;
}

server {
listen 80;
listen [::]:80;
server_name cloud.mydomain.net;
# enforce https
return 301 https://$server_name:443$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name cloud.mydomain.net;

ssl_certificate /etc/letsencrypt/live/cloud.mydomain.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.mydomain.net/privkey.pem;

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

# Path to the root of your installation
root /usr/share/webapps/nextcloud;

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}

# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;

# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;

location / {
rewrite ^ /index.php;
}

location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
deny all;
}
location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}

location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy)\.php(?:$|\/) {
fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
# Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
# Enable pretty urls
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}

location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
try_files $uri/ =404;
index index.php;
}

# Adding the cache control header for js, css and map files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;

# Optional: Don't log access to assets
access_log off;
}

location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$ {
try_files $uri /index.php$request_uri;
# Optional: Don't log access to other assets
access_log off;
}
}</source>
We have to create a data directory for Nextcloud:

<source lang="bash">mkdir /var/nextcloud
chown http:http /var/nextcloud
chmod 750 /var/nextcloud</source>
We also have to change permissions for the apps directories:

<source lang="bash">mkdir -p /usr/share/webapps/nextcloud/data
chown -R http:http /usr/share/webapps/nextcloud/{apps,data}
chmod 750 /usr/share/webapps/nextcloud/{apps,data}</source>
We have to give <code>php-fpm</code> permissions. We do this with the following command:

<source lang="bash">systemctl edit php-fpm.service</source>
This will save the contents in <code>/etc/systemd/system/php-fpm.service.d/override.conf</code>.

The contents:

<source lang="bash">[Service]
ReadWritePaths = /usr/share/webapps/nextcloud/apps
ReadWritePaths = /usr/share/webapps/nextcloud/data
ReadWritePaths = /etc/webapps/nextcloud/config

# Replace the following path with the Nextcloud data directory
ReadWritePaths = /var/nextcloud</source>
We then do:

<source lang="bash">systemctl restart php-fpm</source>
We can then open the firewall on port 80 and 443:

<source lang="bash">systemctl stop fail2ban
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT
iptables-save > /etc/iptables/iptables.rules
ip6tables-save > /etc/iptables/ip6tables.rules
systemctl start fail2ban</source>
== Postinstall ==

It turns out that the cache was not enabled. We do that by adding the following key to <code>/etc/webapps/nextcloud/config/config.php</code>:

<source lang="php">'memcache.local' => '\OC\Memcache\APCu',</source>
Install the following apps:

* talk
* deck
* notes

== Maintenance ==

The services that are run are:

* mariadb
* nginx
* php-fpm

Install Nextcloud on Arch Linux

2020-06-23T20:15:03Z

Pieter: Basic setup of Arch Linux

Pieter log

2020-06-23T19:35:38Z

Pieter: /* Sunday 7 June 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 7 June 2020 =

Install [https://nextcloud.com/ Nextcloud] on the VPS.

= Saturday 6 June 2020 =

Install Arch Linux on a virtual private server to host [https://nextcloud.com/ Nextcloud].

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-06-21T12:09:41Z

Pieter: /* Wednesday 27 May 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Wednesday 27 May 2020 =

Meeting with Benedikt, Holger and Jos Poortvliet from [https://nextcloud.com/ Nextcloud]. We discussed the ideas that we have and asked whether Nextcloud has some form of integration with git and can provide an infrastructure for our ideas on versioning. Nextcloud is essentially a file service with many apps such as Talk providing video conferencing (we used it for the meeting and it worked well). Nextcloud is a fork of Owncloud and years ago I investigated whether Owncloud could help me get rid of Google services but at the time I found it a bit too limited. However, Nextcloud has improved a lot now and it looks very interesting. Jos Poortvliet mentioned that Nextcloud wants to focus on 'flows' with which you can collaborate on files and discuss it in a chat service. Nextcloud provides its own way of versioning but doesn't have git integration. This looks like a really interesting infrastructure for collaboration and we decided to try it out. I will set up a Nextcloud instance on my server in the near future to try it out.

= Monday 25 May 2020 =

Wednesday 27 May Benedikt, Holger, and I will meet with Jos Poortvliet from [https://nextcloud.com/ Nextcloud] to discuss our ideas on [[Improving Versioning]]. I Improved the page a bit and sent a link to Jos.

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-05-25T19:52:29Z

Pieter: /* Wednesday 6 May 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Wednesday 6 May 2020 =

Video conference call with Holger and Benedikt about the Hamburg STEAM Camp and the project on [[Improving Versioning]] (previously known as [[Semantic Versioning]]). Benedikt would try to set up a meeting with a representative of NextCloud to investigate if collaboration would be possible in this area.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-05-25T19:49:41Z

Pieter: /* Sunday 26 April 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Thursday 23 April 2020 =

Video call with Benedikt and Holger about STEAM Camp Hamburg. Unfortunately, the STEAM has been canceled due to the Corona crisis.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-05-25T19:48:12Z

Pieter: /* Saturday 9 May 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 17 May 2020 =

Recording creating a schematic in KiCAD. This is longer than I wanted. I noticed that longer video clips make the editing time also longer, and not in a linear way...

= Sunday 10 May 2020 =

Teaching myself FreeCAD. Notice that the OSE version of FreeCAD is old, either from 2016 or 2018. I believe this is because of the Assembly 2 workbench that is not supported any longer and only works properly in 0.16 from 2016. I've read that they are working on integrating an Assembly workbench natively in FreeCAD. I realized that the assembly modules that OSE currently has are probably not going to be portable to any new version. Assembly 3 and Assembly 4 are not backwards compatible.

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-05-25T19:41:32Z

Pieter: /* Saturday 9 May 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Saturday 9 May 2020 =

Working on the KiCAD 101. Improve the voice-overs. I may need to get a better microphone, and camera as well for that matter. Add notes for the second module on the Pierce oscillator.

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-05-25T19:37:45Z

Pieter: /* Sunday 26 April 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 26 April 2020 =

Working on various clips for the OSE KiCAD 101. Trying to make title templates in Kdenlive to speed up creating different modules. Recording voice overs for the tutorials. Making the minimal Arduino and making it work with the blink program.

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Talk:Semantic Versioning

2020-05-25T17:08:43Z

Pieter: Pieter moved page Talk:Semantic Versioning to Talk:Improving Versioning: The title "Semantic Versioning" is too specific for the proposal.

#REDIRECT [[Talk:Improving Versioning]]

Talk:Improving Versioning

2020-05-25T17:08:43Z

Pieter: Pieter moved page Talk:Semantic Versioning to Talk:Improving Versioning: The title "Semantic Versioning" is too specific for the proposal.

Structure Nextcloud Meeting:

- introduction (we "ose wiki-boost) and nextcloud)

- dgml/fab city/circular economy

- we need light weight content development system (wiki with + features)

- goals/requirements

- wishlist

- discussion/feedback from nextcloud (NC) (what nc can deliver)

- open end / we come back to NC

<hr />

From [[User:Groques]]: For what it's worth, I fully support the [[Semantic Versioning]] proposal and think it's great. Although, I also have a software development background, so I'm already familiar with the concept, and am probably biased.

Semantic versioning was really developed for software. It's worth exploring '''if''' there are cases where it doesn't apply well to '''hardware'''. For example, what's considered a "breaking change" or would require a major version bump for hardware? The lines in hardware may not be as well-defined as they are in software.

Semantic Versioning

2020-05-25T17:08:43Z

Pieter: Pieter moved page Semantic Versioning to Improving Versioning: The title "Semantic Versioning" is too specific for the proposal.

#REDIRECT [[Improving Versioning]]

Improving Versioning

2020-05-25T17:08:43Z

Pieter: Pieter moved page Semantic Versioning to Improving Versioning: The title "Semantic Versioning" is too specific for the proposal.

== Summary ==

* proposal to address issues with consistent versions of machines
* OSE's core business is actually producing documentation for machines available over a lifetime
* Good about the current situation
** proven technology, easy-to-use centralized wiki
** easy to use Google Presentations cloud application for build manuals
* Problems with the current situation
** wiki unstructured and overwhelming
** no real versioning in wiki and Google Presentations
** reliance on volatile, proprietary Google cloud services
** binary format for Google Presentations prevents proper versioning
* Requirements
# no major change in current workflow
# keep the wiki as central point
# do not rely on the wiki as a central point
# apply proper versioning reflecting severity of change
# true consolidation of machines with lifetime releases
# versioning supporting modularity
# no reliance on proprietary software/cloud services
# support textual format as much as possible for universal versioning
# same ease-of-use as Google Presentations
# automatic index for machines, modules, projects on the wiki
* Proposal
** adopt semantic versioning
** adopt Git with submodules
** create lifetime releases with Zenodo or IPFS
** automatically generate wiki pages, build manuals from Git repositories
** find a way to use a textual format as an easy-to-use replacement for Google Presentations
* Concrete steps
** Investigate the above in the Hamburg STEAM Camp

== Introduction ==
Several projects in OSE become viable products, for example the D3D Universal and D3D Pro are being sold as kits. However, the nature of OSE is that many projects are in a high rate of development and versions may change much in a short amount of time. For example, the D3D Universal changed considerably from the summer of 2019 to January 2020 and possibly as a result the documentation on the wiki was not consistent.

On this page we will try to address some the issues. We will first elaborate on the context, then we will discuss what is good in the current situation. We will then define the problem and finally outline a set of ideas and requirement to improve on the status quo.

== Context ==
Many machines are reaching a state that makes them a viable product. For others to be able to use them, we need proper documentation that is consistent over versions. The machines are highly modular which means that some version of machine A uses some version of project B. If B advances, it may no longer be a fit to A. As such, it is necessary to maintain bookkeeping about which version of a different component is used.

We could ask ourselves what OSE's core business is. An acceptable answer would be producing the machines of the GVCS. However, a more refined answer would be that OSE produces documentation to build the machines of the GVCS. To be able to repair them, it is necessary to understand it, hence the documentation.

An interesting feature of the OSE machines is that they should be usable over a lifetime - potentially "indefinite". However, this would also require for the documentation to be available over a lifetime. It is not clear whether that is guaranteed currently.

Another question is then: What does it mean that the machine is available over a lifetime? Is the machine (rather its documentation) built now available in 20 years? Is the documentation of that specific version available? The machines built now are versioned using year and month. Or is only the current documentation available of the machine in the current state?

== Qualities of the current situation ==
The current system in place has various good features. The OSE wiki has pages for each project where information and build manuals are stored. A wiki is proven method with a relatively low entrance threshold for users. The wiki logs changes to the pages and people making the changes. Major benefits are:
* one central point of entry
* anyone can join
* relative ease of use
* logs activity with changes
* proven technology

Many of the build manuals are created in Google Presentations. This is a highly easy-to-use cloud application. Anyone can view the presentation and download it in various formats such as Microsoft Powerpoint, Libre Office, or PDF. It also supports templates to provide a fixed style and the application keeps track of versions although these versions are not available to the public as opposed to the wiki pages.

Although we list qualities here, these qualities are debatable. For example, the wiki's ease of use is relative and highly depends on the user's prior experience with editing wikis. For example, since editing and viewing the rendered results requires extra clicks, the workflow is not ideal. Embedding of external resources is brittle and requires copy-and-pasting of HTML-snippets (and the rendering of these external links depends on the browser's privacy settings).
In addition, although Google Presentations are indeed easy-to-use, keeping formatting consistent can be challenging and time-consuming.

== Problem definition ==
Although there are certainly good things to say about the current situation, unfortunately it is also possible to name deficiencies. One of the problems of the wiki is that it contains lots of information in a more or less unstructered way. Navigation is reliant on links between pages, there is machine information, firmwares, "meta" topics such as this, etc. A common complaint is that users find it hard to find their way and get overwhelmed with the content.

Although a wiki keeps track of changes, it is on a per-page basis and not really meant for versioning. (It is rather a mechanism to make and compare snap-shots.) To the best of my knowledge, it is not impossible to mark a page as being in a state that should be consolidated, for a machine release for example. Furthermore, there is no mechanism to add in-place comments (and comment on comments), which seems desirable for a collaborative workflow and resolving merge conflicts in the wiki is not intuitive.

A problem with the way machines are versioned is that the version number does not reflect how severe a change is. Does a minor change lead to a new version number, for example a new Z-sensor on a 3D-printer? Perhaps it does, it may get version 20.04, but if next month the layout of the axes change, it may get version 20.05, whereas it is a major change. And 3D-printer 20.05 may make use of an improved universal axes but which version? Do we consistently change the 3D-printer version if the universal axis version number changes? Managing these version numbers requires lots of discipline in the current situation.

The build manuals are drafted in Google Presentations but this has drawbacks. Firstly, editing requires a Google account. Secondly, the application is a proprietary cloud application from a major company that has so many resources that they can build an extremely high quality cloud application. However, this results in high degree of [https://en.wikipedia.org/wiki/Vendor_lock-in vendor lock-in]. Google cloud services are highly volatile, see the [https://en.wikipedia.org/wiki/Google_Reader#Discontinuation discontinuation of Google Reader], [https://en.wikipedia.org/wiki/Google%2B Google +], and the number of video conferencing applications that may or may not be merged: Google Meet, Google DUO, Google Hangouts, Google chat, and all of these may or may not be integrated with Gmail. The point is that being reliant on such a large, volatile company where services may be canceled, terms of service may change is not a very "open" way of working.

It is debatable to what degree vendor lock-in is still acceptable as there are also examples without much reliance on a particular cloud service. For example, using GitHub may be acceptable if the repository is mirrored in some form. GitHub's issue tracker may be leveraged because it gives out-of-the-box, user-friendly functionality, but with the understanding that it may go away any time (e.g., because of DMCA take-down.)

More practical issues are the following: The internal format is not exposed to the user. The format is binary instead of textual which makes tracking changes more cumbersome and reliant on the used application.

== Requirements ==
Based on the current qualities and problems we can define a set of requirements:

=== 1) No major change in the status quo ===
The current way of working with the wiki has obvious benefits. Changing the way OSE works in a major way is likely to be unnecessary and a whole community has to make a big change.

=== 2) Keep the wiki as a central point ===
The wiki is a proven technology with a low entrance threshold. It brings a community together in a central place. However, central points have drawbacks, certainly in an open-source project.

=== 3) Do not rely on the wiki as a central point ===
The danger of a central point is that if the wiki goes offline, lots of very interesting information, a legacy, will be lost. It may be possible to protect for this.

Can we download, and backup ALL of the wiki or parts, like one can with wikipedia? Magnetic Tape Cartriges, or archival optical disks are cheap/tb and can last for a long time, two of thos physical in seperate places, and a cloud, and we should be good? (plus frequent backups). Also any way to trigger a wayback machine "copy" ?

=== 4) Apply proper versioning ===
A good approach would be to apply versioning in such a way that a version change reflects the severity of the change.

=== 5) Lifetime releases ===
True consolidation of versions in the form of releases (releases of the documentation) that will never be lost and available for eternity or at least for the lifetime of the machine.

=== 6) Versioning supporting modularity ===
The GVCS machines are highly modular. There should be a proper system in place that can keep track of the various version numbers of the sub-releases.

=== 7) No reliance on proprietary cloud services ===
For an open project as OSE, it would be preferable not to rely on proprietary software, also not on cloud services.

=== 8) Support textual format as much as possible ===
Proper versioning works best with textual formats. For versioning in binary formats one needs support from the application that produces the binary format, whereas versioning on textual formats can be done with any tool. This means that versioning becomes universal.

=== 9) Google Presentations ease-of-use ===
For documentation of the machines, the build manuals, we would like to have the same ease-of-use as Google Presentations offers.

=== 10) Automatic indexing ===
For the machines, the modules that are part of the machines it would be helpful if there were some form of automatic indexing. Essentially, it would be good to have more structure on the wiki.

== Proposal ==
If one agrees that an important objective of OSE is to produce documentation for building machines of the GVCS, then we can look at other fields that deal with structured information. In that case it makes sense to look at software engineering that already has a significant open-source initiative.

=== Semantic versioning ===
Typically, [https://semver.org/ semantic versioning] is used in the field of software engineering. With semantic versioning, a version number has three numbers, for example 2.3.4. With these three numbers one can convey how big a change is. For example from 2.x.x to 3.0.0 is a major change, from 2.3.x to 2.4.0 is a minor change, for example changing a z-sensor on a 3D-printer. A change from 2.3.4 to 2.3.5 is a very minor change, typically to solve a problem. An example is to replace an axis-stop with a new version that works better than the previous version.

This scheme is most dominant in software engineering and it may be wise to learn from it and adopt it. This would satisfy requirement 4.

In addition to semantic versioning, which is linear, we also have to think about accommodating "alternatives/options/configurations". For example, the "same" printer has different components for power supply depending on the region (e.g., US has a US-plug and GFCI, most of Europe has a Europlug, etc.). Printer versions have gone back and forth between 2-pin/3-pin endstops, but it may make sense to have both configurations as user-selectable option (and depending on the choice a matching firmware configuration is needed).

=== Distributed versioning systems ===
Software engineering projecs typically use dedicated versioning systems. There are centralized versioning systems such as the old [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and the still used [https://en.wikipedia.org/wiki/Apache_Subversion SVN]. In these systems committing a change to the software registers the change on a central CVS or SVN server. This is not ideal for open source projects because if an open source project becomes less popular and someone decides to turn off the server, all version history is gone.

Therefore, more popular today are distributed versioning systems such as [https://en.wikipedia.org/wiki/Mercurial Mercurial] or [https://en.wikipedia.org/wiki/Git Git]. Especially Git is very popular. Distributed versioning systems work in a different way. Each user "clones" or receives a copy of the complete version history of the project. If a centralized repository is discontinued, any user can reignite the project. In addition, committing changes and registering these changes to a repository is decoupled.

An extra feature of for example git is submodules. A submodule is a Git repository inside a Git repository. The parent repository keeps track of a specific commit of a child repository. This mechanism can help us to keep track of modules, for example, version 1.0.0 of the D3D-Universal uses version 0.8.2 of the Universal Axis. Version 1.5.0 of the D3D-Universal however has changed to version 1.0.2 of the Universal Axis.

Git repositories typically have a ''master'' "branch", where a branch can be considered a chain of ''commits''. A commit is a change in the repository made by a user, for example fixing a typo, update a version number, or big changes such as removing many files. Many people can collaborate on a project by creating their own branch, for example 'add-second-z-axis', or 'fix-z-sensor-problem'. The people working on these branches commit in these branches and at some point they are ready and want to merge their branch into the master branch. This is essentially updating the master branch to add the new feature. The merge itself is also considered a commit. For example if both 'add-second-z-axis' and 'fix-z-sensor-problem' are ready and merged into master, the team could decide that this could become a new version. They can then 'tag' the current commit with the version number, for example 'v1.3.0'.

It seems using Git would also require some kind of (more or less) formalized process/workflow that spells out who can do what changes. Git is workflow-agnostic (a mixed blessing) and there are [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows reference workflows] that could be used or adapted. (For example, FreeCAD uses the [https://wiki.freecadweb.org/Source_code_management "dictator and lieutenants workflow"].)

The benefit of Git is that people can collaborate in a structured way, it supports semantic versioning. The repositories are decentralized which means that losing the history of a project is unlikely. Adopting Git would satisfy requirements 6. It would help requirement 3 and 4. However, it may be a disruptive change opposing requirement 1.

=== Lifetime releases ===
There are multiple ways to satisfy requirement 5, lifetime releases. First, proper versioning (requirement 4) has to be established. One way to create releases for eternity is by using [https://zenodo.org/ Zenodo]. Zenodo is a project by CERN with funding from the European Union. It is a data repository using the infrastructure of the Large Hadron Collider. It allows you to take a snapshot of a Git repository and associate a unique [https://en.wikipedia.org/wiki/Digital_object_identifier DOI] to it. This basically ensures that releases will be around for eternity.

Another solution is to use the [https://ipfs.io/ InterPlanetary File System] where we can store and possibly 'pin' versions for eternity. This relies on having multiple copies of the versions hosted by different nodes in the network.

=== Generating wiki pages ===
As the benefit of the wiki is clear, we need some way of bringing all of the above together. A proposal is to move serious development of the machines to a dedicated Git repository, for example 'univeral-axis' and 'd3d-universal'. The Git repositories contain a LICENSE file, a README, a CONTRIBUTING, a Changelog file, a VERSION file, and a Makefile, just as in a open-source software project. The README explains how the repository works, for what machine the repository is, etc. The CONTRIBUTING file defines a set of guidelines to aid users in contributing content. The Makefile is essentially a script that keeps track of dependencies between files and 'builds' the project, we will come back to this later. The other files are self-explanatory.

The main content of the repository consists of documentation in textual format together with the CAD files of the project. With all this content we can 'build' the project which means in this situation that we generate documents for the machines. An example would be to 'make' the build manual or 'make' the wiki page of the project, or 'make' the BOM. The make script would ideally automatically generate images from the CAD files to be used in the documents that this project generates. (This seems feasible for FreeCAD [[https://wiki.freecadweb.org/Std_ViewScreenShot]], since it can be scripted and run headless.)

As such, we can generate a wiki page and add that to the wiki ensuring that the information on the wiki remains consistent. We could also automatically create an index for the wiki for several of these project, satisfying requirement 10.

Ideally, we could even try to support to automatically incorporate editing actions on the wiki page back into the git repository to make sure that regular users can still contribute in a user-friendly way. (This can be seen as a form of [https://en.wikipedia.org/wiki/Round-trip_engineering round-trip engineering].)

Unfortunately, all of this, does not fully satisfy requirement 1. However, the benefits may outweigh the change. It does satisfy requirement 2 and because of the decentralized nature of Git repositories it satisfies requirement 3. Git is an extremely powerful tool but therefore also difficult to use. However, the basic required commands are easy to use and learn with proper documentation and tutorials. Therefore, the overall ease of use is diminished (requirement 9).

=== Textual format ===
To make this all work, it would be ideal if most of the content in the repository is textual since it helps keeping track of changes easily. Binary files increase the size of the repository (every new commit with a binary file increases the size of the repository with the size of the file) and it is impossible to see what change was made. Unfortunately FreeCAD files are also binary, but because it is essentially a ZIP file, we could make Git a bit smarter to allow proper versioning on these files as well.

To satisfy requirement 7, moving away from Google while maintaining the same ease-of-use (requirement 9) together with supporting a textual format (requirement 8) is an open question. One could think of using the [https://en.wikipedia.org/wiki/Markdown Markdown] format in combination with [https://pandoc.org/ Pandoc] to convert it to various other formats. Another option is [https://orgmode.org/ Org mode] that has excellent integration with the [https://www.gnu.org/software/emacs/ Emacs] editor.

=== Mirror the OSE Wiki ===
To satisfy requirement 3, one may mirror the OSE wiki on separate server or an ipfs. Then, if the main OSE wiki went offline, it could be reignited.

== Concrete Steps ==
A proposal is to investigate all of this as part of the STEAM Camp Hamburg. A good use case is to apply the above methodology to the D3D-Univeral. After this experiment, we can evaluate this methodology compared to the current workflow.

=See Also=
*

=Useful Links=
*[https://www.youtube.com/watch?v=gShRBsahzXg A Youtube Video on USB's Recent Failure at Naming Standards Reflecting Change, and Making Sense]

Improving Versioning

2020-05-25T15:56:31Z

Pieter: /* 3) Do not rely on the wiki as a central point */

Improving Versioning

2020-05-25T15:51:10Z

Pieter: /* Problem definition */

== Summary ==

* proposal to address issues with consistent versions of machines
* OSE's core business is actually producing documentation for machines available over a lifetime
* Good about the current situation
** proven technology, easy-to-use centralized wiki
** easy to use Google Presentations cloud application for build manuals
* Problems with the current situation
** wiki unstructured and overwhelming
** no real versioning in wiki and Google Presentations
** reliance on volatile, proprietary Google cloud services
** binary format for Google Presentations prevents proper versioning
* Requirements
# no major change in current workflow
# keep the wiki as central point
# do not rely on the wiki as a central point
# apply proper versioning reflecting severity of change
# true consolidation of machines with lifetime releases
# versioning supporting modularity
# no reliance on proprietary software/cloud services
# support textual format as much as possible for universal versioning
# same ease-of-use as Google Presentations
# automatic index for machines, modules, projects on the wiki
* Proposal
** adopt semantic versioning
** adopt Git with submodules
** create lifetime releases with Zenodo or IPFS
** automatically generate wiki pages, build manuals from Git repositories
** find a way to use a textual format as an easy-to-use replacement for Google Presentations
* Concrete steps
** Investigate the above in the Hamburg STEAM Camp

== Introduction ==
Several projects in OSE become viable products, for example the D3D Universal and D3D Pro are being sold as kits. However, the nature of OSE is that many projects are in a high rate of development and versions may change much in a short amount of time. For example, the D3D Universal changed considerably from the summer of 2019 to January 2020 and possibly as a result the documentation on the wiki was not consistent.

On this page we will try to address some the issues. We will first elaborate on the context, then we will discuss what is good in the current situation. We will then define the problem and finally outline a set of ideas and requirement to improve on the status quo.

== Context ==
Many machines are reaching a state that makes them a viable product. For others to be able to use them, we need proper documentation that is consistent over versions. The machines are highly modular which means that some version of machine A uses some version of project B. If B advances, it may no longer be a fit to A. As such, it is necessary to maintain bookkeeping about which version of a different component is used.

We could ask ourselves what OSE's core business is. An acceptable answer would be producing the machines of the GVCS. However, a more refined answer would be that OSE produces documentation to build the machines of the GVCS. To be able to repair them, it is necessary to understand it, hence the documentation.

An interesting feature of the OSE machines is that they should be usable over a lifetime - potentially "indefinite". However, this would also require for the documentation to be available over a lifetime. It is not clear whether that is guaranteed currently.

Another question is then: What does it mean that the machine is available over a lifetime? Is the machine (rather its documentation) built now available in 20 years? Is the documentation of that specific version available? The machines built now are versioned using year and month. Or is only the current documentation available of the machine in the current state?

== Qualities of the current situation ==
The current system in place has various good features. The OSE wiki has pages for each project where information and build manuals are stored. A wiki is proven method with a relatively low entrance threshold for users. The wiki logs changes to the pages and people making the changes. Major benefits are:
* one central point of entry
* anyone can join
* relative ease of use
* logs activity with changes
* proven technology

Many of the build manuals are created in Google Presentations. This is a highly easy-to-use cloud application. Anyone can view the presentation and download it in various formats such as Microsoft Powerpoint, Libre Office, or PDF. It also supports templates to provide a fixed style and the application keeps track of versions although these versions are not available to the public as opposed to the wiki pages.

Although we list qualities here, these qualities are debatable. For example, the wiki's ease of use is relative and highly depends on the user's prior experience with editing wikis. For example, since editing and viewing the rendered results requires extra clicks, the workflow is not ideal. Embedding of external resources is brittle and requires copy-and-pasting of HTML-snippets (and the rendering of these external links depends on the browser's privacy settings).
In addition, although Google Presentations are indeed easy-to-use, keeping formatting consistent can be challenging and time-consuming.

== Problem definition ==
Although there are certainly good things to say about the current situation, unfortunately it is also possible to name deficiencies. One of the problems of the wiki is that it contains lots of information in a more or less unstructered way. Navigation is reliant on links between pages, there is machine information, firmwares, "meta" topics such as this, etc. A common complaint is that users find it hard to find their way and get overwhelmed with the content.

Although a wiki keeps track of changes, it is on a per-page basis and not really meant for versioning. (It is rather a mechanism to make and compare snap-shots.) To the best of my knowledge, it is not impossible to mark a page as being in a state that should be consolidated, for a machine release for example. Furthermore, there is no mechanism to add in-place comments (and comment on comments), which seems desirable for a collaborative workflow and resolving merge conflicts in the wiki is not intuitive.

A problem with the way machines are versioned is that the version number does not reflect how severe a change is. Does a minor change lead to a new version number, for example a new Z-sensor on a 3D-printer? Perhaps it does, it may get version 20.04, but if next month the layout of the axes change, it may get version 20.05, whereas it is a major change. And 3D-printer 20.05 may make use of an improved universal axes but which version? Do we consistently change the 3D-printer version if the universal axis version number changes? Managing these version numbers requires lots of discipline in the current situation.

The build manuals are drafted in Google Presentations but this has drawbacks. Firstly, editing requires a Google account. Secondly, the application is a proprietary cloud application from a major company that has so many resources that they can build an extremely high quality cloud application. However, this results in high degree of [https://en.wikipedia.org/wiki/Vendor_lock-in vendor lock-in]. Google cloud services are highly volatile, see the [https://en.wikipedia.org/wiki/Google_Reader#Discontinuation discontinuation of Google Reader], [https://en.wikipedia.org/wiki/Google%2B Google +], and the number of video conferencing applications that may or may not be merged: Google Meet, Google DUO, Google Hangouts, Google chat, and all of these may or may not be integrated with Gmail. The point is that being reliant on such a large, volatile company where services may be canceled, terms of service may change is not a very "open" way of working.

It is debatable to what degree vendor lock-in is still acceptable as there are also examples without much reliance on a particular cloud service. For example, using GitHub may be acceptable if the repository is mirrored in some form. GitHub's issue tracker may be leveraged because it gives out-of-the-box, user-friendly functionality, but with the understanding that it may go away any time (e.g., because of DMCA take-down.)

More practical issues are the following: The internal format is not exposed to the user. The format is binary instead of textual which makes tracking changes more cumbersome and reliant on the used application.

== Requirements ==
Based on the current qualities and problems we can define a set of requirements:

=== 1) No major change in the status quo ===
The current way of working with the wiki has obvious benefits. Changing the way OSE works in a major way is likely to be unnecessary and a whole community has to make a big change.

=== 2) Keep the wiki as a central point ===
The wiki is a proven technology with a low entrance threshold. It brings a community together in a central place. However, central points have drawbacks, certainly in an open-source project.

=== 3) Do not rely on the wiki as a central point ===
The danger of a central point is that if the wiki goes offline, lots of very interesting information, a legacy, will be lost. It may be possible to protect for this.
'''Can we download, and backup ALL of the wiki or parts, like one can with wikipedia? Magnetic Tape Cartriges, or archival optical disks are cheap/tb and can last for a long time, two of thos physical in seperate places, and a cloud, and we should be good? (plus frequent backups). Also any way to trigger a wayback machine "copy" ? '''

=== 4) Apply proper versioning ===
A good approach would be to apply versioning in such a way that a version change reflects the severity of the change.

=== 5) Lifetime releases ===
True consolidation of versions in the form of releases (releases of the documentation) that will never be lost and available for eternity or at least for the lifetime of the machine.

=== 6) Versioning supporting modularity ===
The GVCS machines are highly modular. There should be a proper system in place that can keep track of the various version numbers of the sub-releases.

=== 7) No reliance on proprietary cloud services ===
For an open project as OSE, it would be preferable not to rely on proprietary software, also not on cloud services.

=== 8) Support textual format as much as possible ===
Proper versioning works best with textual formats. For versioning in binary formats one needs support from the application that produces the binary format, whereas versioning on textual formats can be done with any tool. This means that versioning becomes universal.

=== 9) Google Presentations ease-of-use ===
For documentation of the machines, the build manuals, we would like to have the same ease-of-use as Google Presentations offers.

=== 10) Automatic indexing ===
For the machines, the modules that are part of the machines it would be helpful if there were some form of automatic indexing. Essentially, it would be good to have more structure on the wiki.

== Proposal ==
If one agrees that an important objective of OSE is to produce documentation for building machines of the GVCS, then we can look at other fields that deal with structured information. In that case it makes sense to look at software engineering that already has a significant open-source initiative.

=== Semantic versioning ===
Typically, [https://semver.org/ semantic versioning] is used in the field of software engineering. With semantic versioning, a version number has three numbers, for example 2.3.4. With these three numbers one can convey how big a change is. For example from 2.x.x to 3.0.0 is a major change, from 2.3.x to 2.4.0 is a minor change, for example changing a z-sensor on a 3D-printer. A change from 2.3.4 to 2.3.5 is a very minor change, typically to solve a problem. An example is to replace an axis-stop with a new version that works better than the previous version.

This scheme is most dominant in software engineering and it may be wise to learn from it and adopt it. This would satisfy requirement 4.

In addition to semantic versioning, which is linear, we also have to think about accommodating "alternatives/options/configurations". For example, the "same" printer has different components for power supply depending on the region (e.g., US has a US-plug and GFCI, most of Europe has a Europlug, etc.). Printer versions have gone back and forth between 2-pin/3-pin endstops, but it may make sense to have both configurations as user-selectable option (and depending on the choice a matching firmware configuration is needed).

=== Distributed versioning systems ===
Software engineering projecs typically use dedicated versioning systems. There are centralized versioning systems such as the old [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and the still used [https://en.wikipedia.org/wiki/Apache_Subversion SVN]. In these systems committing a change to the software registers the change on a central CVS or SVN server. This is not ideal for open source projects because if an open source project becomes less popular and someone decides to turn off the server, all version history is gone.

Therefore, more popular today are distributed versioning systems such as [https://en.wikipedia.org/wiki/Mercurial Mercurial] or [https://en.wikipedia.org/wiki/Git Git]. Especially Git is very popular. Distributed versioning systems work in a different way. Each user "clones" or receives a copy of the complete version history of the project. If a centralized repository is discontinued, any user can reignite the project. In addition, committing changes and registering these changes to a repository is decoupled.

An extra feature of for example git is submodules. A submodule is a Git repository inside a Git repository. The parent repository keeps track of a specific commit of a child repository. This mechanism can help us to keep track of modules, for example, version 1.0.0 of the D3D-Universal uses version 0.8.2 of the Universal Axis. Version 1.5.0 of the D3D-Universal however has changed to version 1.0.2 of the Universal Axis.

Git repositories typically have a ''master'' "branch", where a branch can be considered a chain of ''commits''. A commit is a change in the repository made by a user, for example fixing a typo, update a version number, or big changes such as removing many files. Many people can collaborate on a project by creating their own branch, for example 'add-second-z-axis', or 'fix-z-sensor-problem'. The people working on these branches commit in these branches and at some point they are ready and want to merge their branch into the master branch. This is essentially updating the master branch to add the new feature. The merge itself is also considered a commit. For example if both 'add-second-z-axis' and 'fix-z-sensor-problem' are ready and merged into master, the team could decide that this could become a new version. They can then 'tag' the current commit with the version number, for example 'v1.3.0'.

It seems using Git would also require some kind of (more or less) formalized process/workflow that spells out who can do what changes. Git is workflow-agnostic (a mixed blessing) and there are [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows reference workflows] that could be used or adapted. (For example, FreeCAD uses the [https://wiki.freecadweb.org/Source_code_management "dictator and lieutenants workflow"].)

The benefit of Git is that people can collaborate in a structured way, it supports semantic versioning. The repositories are decentralized which means that losing the history of a project is unlikely. Adopting Git would satisfy requirements 6. It would help requirement 3 and 4. However, it may be a disruptive change opposing requirement 1.

=== Lifetime releases ===
There are multiple ways to satisfy requirement 5, lifetime releases. First, proper versioning (requirement 4) has to be established. One way to create releases for eternity is by using [https://zenodo.org/ Zenodo]. Zenodo is a project by CERN with funding from the European Union. It is a data repository using the infrastructure of the Large Hadron Collider. It allows you to take a snapshot of a Git repository and associate a unique [https://en.wikipedia.org/wiki/Digital_object_identifier DOI] to it. This basically ensures that releases will be around for eternity.

Another solution is to use the [https://ipfs.io/ InterPlanetary File System] where we can store and possibly 'pin' versions for eternity. This relies on having multiple copies of the versions hosted by different nodes in the network.

=== Generating wiki pages ===
As the benefit of the wiki is clear, we need some way of bringing all of the above together. A proposal is to move serious development of the machines to a dedicated Git repository, for example 'univeral-axis' and 'd3d-universal'. The Git repositories contain a LICENSE file, a README, a CONTRIBUTING, a Changelog file, a VERSION file, and a Makefile, just as in a open-source software project. The README explains how the repository works, for what machine the repository is, etc. The CONTRIBUTING file defines a set of guidelines to aid users in contributing content. The Makefile is essentially a script that keeps track of dependencies between files and 'builds' the project, we will come back to this later. The other files are self-explanatory.

The main content of the repository consists of documentation in textual format together with the CAD files of the project. With all this content we can 'build' the project which means in this situation that we generate documents for the machines. An example would be to 'make' the build manual or 'make' the wiki page of the project, or 'make' the BOM. The make script would ideally automatically generate images from the CAD files to be used in the documents that this project generates. (This seems feasible for FreeCAD [[https://wiki.freecadweb.org/Std_ViewScreenShot]], since it can be scripted and run headless.)

As such, we can generate a wiki page and add that to the wiki ensuring that the information on the wiki remains consistent. We could also automatically create an index for the wiki for several of these project, satisfying requirement 10.

Ideally, we could even try to support to automatically incorporate editing actions on the wiki page back into the git repository to make sure that regular users can still contribute in a user-friendly way. (This can be seen as a form of [https://en.wikipedia.org/wiki/Round-trip_engineering round-trip engineering].)

Unfortunately, all of this, does not fully satisfy requirement 1. However, the benefits may outweigh the change. It does satisfy requirement 2 and because of the decentralized nature of Git repositories it satisfies requirement 3. Git is an extremely powerful tool but therefore also difficult to use. However, the basic required commands are easy to use and learn with proper documentation and tutorials. Therefore, the overall ease of use is diminished (requirement 9).

=== Textual format ===
To make this all work, it would be ideal if most of the content in the repository is textual since it helps keeping track of changes easily. Binary files increase the size of the repository (every new commit with a binary file increases the size of the repository with the size of the file) and it is impossible to see what change was made. Unfortunately FreeCAD files are also binary, but because it is essentially a ZIP file, we could make Git a bit smarter to allow proper versioning on these files as well.

To satisfy requirement 7, moving away from Google while maintaining the same ease-of-use (requirement 9) together with supporting a textual format (requirement 8) is an open question. One could think of using the [https://en.wikipedia.org/wiki/Markdown Markdown] format in combination with [https://pandoc.org/ Pandoc] to convert it to various other formats. Another option is [https://orgmode.org/ Org mode] that has excellent integration with the [https://www.gnu.org/software/emacs/ Emacs] editor.

=== Mirror the OSE Wiki ===
To satisfy requirement 3, one may mirror the OSE wiki on separate server or an ipfs. Then, if the main OSE wiki went offline, it could be reignited.

== Concrete Steps ==
A proposal is to investigate all of this as part of the STEAM Camp Hamburg. A good use case is to apply the above methodology to the D3D-Univeral. After this experiment, we can evaluate this methodology compared to the current workflow.

=See Also=
*

=Useful Links=
*[https://www.youtube.com/watch?v=gShRBsahzXg A Youtube Video on USB's Recent Failure at Naming Standards Reflecting Change, and Making Sense]

Improving Versioning

2020-05-25T15:45:53Z

Pieter: /* Qualities of the current situation */

== Summary ==

* proposal to address issues with consistent versions of machines
* OSE's core business is actually producing documentation for machines available over a lifetime
* Good about the current situation
** proven technology, easy-to-use centralized wiki
** easy to use Google Presentations cloud application for build manuals
* Problems with the current situation
** wiki unstructured and overwhelming
** no real versioning in wiki and Google Presentations
** reliance on volatile, proprietary Google cloud services
** binary format for Google Presentations prevents proper versioning
* Requirements
# no major change in current workflow
# keep the wiki as central point
# do not rely on the wiki as a central point
# apply proper versioning reflecting severity of change
# true consolidation of machines with lifetime releases
# versioning supporting modularity
# no reliance on proprietary software/cloud services
# support textual format as much as possible for universal versioning
# same ease-of-use as Google Presentations
# automatic index for machines, modules, projects on the wiki
* Proposal
** adopt semantic versioning
** adopt Git with submodules
** create lifetime releases with Zenodo or IPFS
** automatically generate wiki pages, build manuals from Git repositories
** find a way to use a textual format as an easy-to-use replacement for Google Presentations
* Concrete steps
** Investigate the above in the Hamburg STEAM Camp

== Introduction ==
Several projects in OSE become viable products, for example the D3D Universal and D3D Pro are being sold as kits. However, the nature of OSE is that many projects are in a high rate of development and versions may change much in a short amount of time. For example, the D3D Universal changed considerably from the summer of 2019 to January 2020 and possibly as a result the documentation on the wiki was not consistent.

On this page we will try to address some the issues. We will first elaborate on the context, then we will discuss what is good in the current situation. We will then define the problem and finally outline a set of ideas and requirement to improve on the status quo.

== Context ==
Many machines are reaching a state that makes them a viable product. For others to be able to use them, we need proper documentation that is consistent over versions. The machines are highly modular which means that some version of machine A uses some version of project B. If B advances, it may no longer be a fit to A. As such, it is necessary to maintain bookkeeping about which version of a different component is used.

We could ask ourselves what OSE's core business is. An acceptable answer would be producing the machines of the GVCS. However, a more refined answer would be that OSE produces documentation to build the machines of the GVCS. To be able to repair them, it is necessary to understand it, hence the documentation.

An interesting feature of the OSE machines is that they should be usable over a lifetime - potentially "indefinite". However, this would also require for the documentation to be available over a lifetime. It is not clear whether that is guaranteed currently.

Another question is then: What does it mean that the machine is available over a lifetime? Is the machine (rather its documentation) built now available in 20 years? Is the documentation of that specific version available? The machines built now are versioned using year and month. Or is only the current documentation available of the machine in the current state?

== Qualities of the current situation ==
The current system in place has various good features. The OSE wiki has pages for each project where information and build manuals are stored. A wiki is proven method with a relatively low entrance threshold for users. The wiki logs changes to the pages and people making the changes. Major benefits are:
* one central point of entry
* anyone can join
* relative ease of use
* logs activity with changes
* proven technology

Many of the build manuals are created in Google Presentations. This is a highly easy-to-use cloud application. Anyone can view the presentation and download it in various formats such as Microsoft Powerpoint, Libre Office, or PDF. It also supports templates to provide a fixed style and the application keeps track of versions although these versions are not available to the public as opposed to the wiki pages.

Although we list qualities here, these qualities are debatable. For example, the wiki's ease of use is relative and highly depends on the user's prior experience with editing wikis. For example, since editing and viewing the rendered results requires extra clicks, the workflow is not ideal. Embedding of external resources is brittle and requires copy-and-pasting of HTML-snippets (and the rendering of these external links depends on the browser's privacy settings).
In addition, although Google Presentations are indeed easy-to-use, keeping formatting consistent can be challenging and time-consuming.

== Problem definition ==
Although there are certainly good things to say about the current situation, unfortunately it is also possible to name deficiencies. One of the problems of the wiki is that it contains lots of information in a more or less unstructered way. Navigation is reliant on links between pages, there is machine information, firmwares, "meta" topics such as this, etc. A common complaint is that users find it hard to find their way and get overwhelmed with the content.

Although a wiki keeps track of changes, it is on a per-page basis and not really meant for versioning. (It is rather a mechanism to make and compare snap-shots.) To the best of my knowledge, it is not impossible to mark a page as being in a state that should be consolidated, for a machine release for example.

Furthermore, there is no mechanism to add in-place comments (and comment on comments), which seems desirable for a collaborative workflow.

Resolving merge conflicts in the wiki is not intuitive and seems a nightmare!!

A problem with the way machines are versioned is that the version number does not reflect how severe a change is. Does a minor change lead to a new version number, for example a new Z-sensor on a 3D-printer? Perhaps it does, it may get version 20.04, but if next month the layout of the axes change, it may get version 20.05, whereas it is a major change. And 3D-printer 20.05 may make use of an improved universal axes but which version? Do we consistently change the 3D-printer version if the universal axis version number changes? Managing these version numbers requires lots of discipline in the current situation.

The build manuals are drafted in Google Presentations but this has drawbacks. Firstly, editing requires a Google account. Secondly, the application is a proprietary cloud application from a major company that has so many resources that they can build an extremely high quality cloud application. However, this results in high degree of [https://en.wikipedia.org/wiki/Vendor_lock-in vendor lock-in]. Google cloud services are highly volatile, see the [https://en.wikipedia.org/wiki/Google_Reader#Discontinuation discontinuation of Google Reader], [https://en.wikipedia.org/wiki/Google%2B Google +], and the number of video conferencing applications that may or may not be merged: Google Meet, Google DUO, Google Hangouts, Google chat, and all of these may or may not be integrated with Gmail. The point is that being reliant on such a large, volatile company where services may be canceled, terms of service may change is not a very "open" way of working.

More generally speaking, it may be useful to evaluate what degree of vendor lock-in in still acceptable. For example, using GitHub may be acceptable if the repository is mirrored in some form. GitHub's issue tracker may be leveraged because it gives out-of-the-box, user-friendly functionality, but with the understanding that it may go away any time (e.g., because of DMCA take-down.)

More practical issues are the following: The internal format is not exposed to the user. The format is binary instead of textual which makes tracking changes more cumbersome and reliant on the used application.

== Requirements ==
Based on the current qualities and problems we can define a set of requirements:

=== 1) No major change in the status quo ===
The current way of working with the wiki has obvious benefits. Changing the way OSE works in a major way is likely to be unnecessary and a whole community has to make a big change.

=== 2) Keep the wiki as a central point ===
The wiki is a proven technology with a low entrance threshold. It brings a community together in a central place. However, central points have drawbacks, certainly in an open-source project.

=== 3) Do not rely on the wiki as a central point ===
The danger of a central point is that if the wiki goes offline, lots of very interesting information, a legacy, will be lost. It may be possible to protect for this.
'''Can we download, and backup ALL of the wiki or parts, like one can with wikipedia? Magnetic Tape Cartriges, or archival optical disks are cheap/tb and can last for a long time, two of thos physical in seperate places, and a cloud, and we should be good? (plus frequent backups). Also any way to trigger a wayback machine "copy" ? '''

=== 4) Apply proper versioning ===
A good approach would be to apply versioning in such a way that a version change reflects the severity of the change.

=== 5) Lifetime releases ===
True consolidation of versions in the form of releases (releases of the documentation) that will never be lost and available for eternity or at least for the lifetime of the machine.

=== 6) Versioning supporting modularity ===
The GVCS machines are highly modular. There should be a proper system in place that can keep track of the various version numbers of the sub-releases.

=== 7) No reliance on proprietary cloud services ===
For an open project as OSE, it would be preferable not to rely on proprietary software, also not on cloud services.

=== 8) Support textual format as much as possible ===
Proper versioning works best with textual formats. For versioning in binary formats one needs support from the application that produces the binary format, whereas versioning on textual formats can be done with any tool. This means that versioning becomes universal.

=== 9) Google Presentations ease-of-use ===
For documentation of the machines, the build manuals, we would like to have the same ease-of-use as Google Presentations offers.

=== 10) Automatic indexing ===
For the machines, the modules that are part of the machines it would be helpful if there were some form of automatic indexing. Essentially, it would be good to have more structure on the wiki.

== Proposal ==
If one agrees that an important objective of OSE is to produce documentation for building machines of the GVCS, then we can look at other fields that deal with structured information. In that case it makes sense to look at software engineering that already has a significant open-source initiative.

=== Semantic versioning ===
Typically, [https://semver.org/ semantic versioning] is used in the field of software engineering. With semantic versioning, a version number has three numbers, for example 2.3.4. With these three numbers one can convey how big a change is. For example from 2.x.x to 3.0.0 is a major change, from 2.3.x to 2.4.0 is a minor change, for example changing a z-sensor on a 3D-printer. A change from 2.3.4 to 2.3.5 is a very minor change, typically to solve a problem. An example is to replace an axis-stop with a new version that works better than the previous version.

This scheme is most dominant in software engineering and it may be wise to learn from it and adopt it. This would satisfy requirement 4.

In addition to semantic versioning, which is linear, we also have to think about accommodating "alternatives/options/configurations". For example, the "same" printer has different components for power supply depending on the region (e.g., US has a US-plug and GFCI, most of Europe has a Europlug, etc.). Printer versions have gone back and forth between 2-pin/3-pin endstops, but it may make sense to have both configurations as user-selectable option (and depending on the choice a matching firmware configuration is needed).

=== Distributed versioning systems ===
Software engineering projecs typically use dedicated versioning systems. There are centralized versioning systems such as the old [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and the still used [https://en.wikipedia.org/wiki/Apache_Subversion SVN]. In these systems committing a change to the software registers the change on a central CVS or SVN server. This is not ideal for open source projects because if an open source project becomes less popular and someone decides to turn off the server, all version history is gone.

Therefore, more popular today are distributed versioning systems such as [https://en.wikipedia.org/wiki/Mercurial Mercurial] or [https://en.wikipedia.org/wiki/Git Git]. Especially Git is very popular. Distributed versioning systems work in a different way. Each user "clones" or receives a copy of the complete version history of the project. If a centralized repository is discontinued, any user can reignite the project. In addition, committing changes and registering these changes to a repository is decoupled.

An extra feature of for example git is submodules. A submodule is a Git repository inside a Git repository. The parent repository keeps track of a specific commit of a child repository. This mechanism can help us to keep track of modules, for example, version 1.0.0 of the D3D-Universal uses version 0.8.2 of the Universal Axis. Version 1.5.0 of the D3D-Universal however has changed to version 1.0.2 of the Universal Axis.

Git repositories typically have a ''master'' "branch", where a branch can be considered a chain of ''commits''. A commit is a change in the repository made by a user, for example fixing a typo, update a version number, or big changes such as removing many files. Many people can collaborate on a project by creating their own branch, for example 'add-second-z-axis', or 'fix-z-sensor-problem'. The people working on these branches commit in these branches and at some point they are ready and want to merge their branch into the master branch. This is essentially updating the master branch to add the new feature. The merge itself is also considered a commit. For example if both 'add-second-z-axis' and 'fix-z-sensor-problem' are ready and merged into master, the team could decide that this could become a new version. They can then 'tag' the current commit with the version number, for example 'v1.3.0'.

It seems using Git would also require some kind of (more or less) formalized process/workflow that spells out who can do what changes. Git is workflow-agnostic (a mixed blessing) and there are [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows reference workflows] that could be used or adapted. (For example, FreeCAD uses the [https://wiki.freecadweb.org/Source_code_management "dictator and lieutenants workflow"].)

The benefit of Git is that people can collaborate in a structured way, it supports semantic versioning. The repositories are decentralized which means that losing the history of a project is unlikely. Adopting Git would satisfy requirements 6. It would help requirement 3 and 4. However, it may be a disruptive change opposing requirement 1.

=== Lifetime releases ===
There are multiple ways to satisfy requirement 5, lifetime releases. First, proper versioning (requirement 4) has to be established. One way to create releases for eternity is by using [https://zenodo.org/ Zenodo]. Zenodo is a project by CERN with funding from the European Union. It is a data repository using the infrastructure of the Large Hadron Collider. It allows you to take a snapshot of a Git repository and associate a unique [https://en.wikipedia.org/wiki/Digital_object_identifier DOI] to it. This basically ensures that releases will be around for eternity.

Another solution is to use the [https://ipfs.io/ InterPlanetary File System] where we can store and possibly 'pin' versions for eternity. This relies on having multiple copies of the versions hosted by different nodes in the network.

=== Generating wiki pages ===
As the benefit of the wiki is clear, we need some way of bringing all of the above together. A proposal is to move serious development of the machines to a dedicated Git repository, for example 'univeral-axis' and 'd3d-universal'. The Git repositories contain a LICENSE file, a README, a CONTRIBUTING, a Changelog file, a VERSION file, and a Makefile, just as in a open-source software project. The README explains how the repository works, for what machine the repository is, etc. The CONTRIBUTING file defines a set of guidelines to aid users in contributing content. The Makefile is essentially a script that keeps track of dependencies between files and 'builds' the project, we will come back to this later. The other files are self-explanatory.

The main content of the repository consists of documentation in textual format together with the CAD files of the project. With all this content we can 'build' the project which means in this situation that we generate documents for the machines. An example would be to 'make' the build manual or 'make' the wiki page of the project, or 'make' the BOM. The make script would ideally automatically generate images from the CAD files to be used in the documents that this project generates. (This seems feasible for FreeCAD [[https://wiki.freecadweb.org/Std_ViewScreenShot]], since it can be scripted and run headless.)

As such, we can generate a wiki page and add that to the wiki ensuring that the information on the wiki remains consistent. We could also automatically create an index for the wiki for several of these project, satisfying requirement 10.

Ideally, we could even try to support to automatically incorporate editing actions on the wiki page back into the git repository to make sure that regular users can still contribute in a user-friendly way. (This can be seen as a form of [https://en.wikipedia.org/wiki/Round-trip_engineering round-trip engineering].)

Unfortunately, all of this, does not fully satisfy requirement 1. However, the benefits may outweigh the change. It does satisfy requirement 2 and because of the decentralized nature of Git repositories it satisfies requirement 3. Git is an extremely powerful tool but therefore also difficult to use. However, the basic required commands are easy to use and learn with proper documentation and tutorials. Therefore, the overall ease of use is diminished (requirement 9).

=== Textual format ===
To make this all work, it would be ideal if most of the content in the repository is textual since it helps keeping track of changes easily. Binary files increase the size of the repository (every new commit with a binary file increases the size of the repository with the size of the file) and it is impossible to see what change was made. Unfortunately FreeCAD files are also binary, but because it is essentially a ZIP file, we could make Git a bit smarter to allow proper versioning on these files as well.

To satisfy requirement 7, moving away from Google while maintaining the same ease-of-use (requirement 9) together with supporting a textual format (requirement 8) is an open question. One could think of using the [https://en.wikipedia.org/wiki/Markdown Markdown] format in combination with [https://pandoc.org/ Pandoc] to convert it to various other formats. Another option is [https://orgmode.org/ Org mode] that has excellent integration with the [https://www.gnu.org/software/emacs/ Emacs] editor.

=== Mirror the OSE Wiki ===
To satisfy requirement 3, one may mirror the OSE wiki on separate server or an ipfs. Then, if the main OSE wiki went offline, it could be reignited.

== Concrete Steps ==
A proposal is to investigate all of this as part of the STEAM Camp Hamburg. A good use case is to apply the above methodology to the D3D-Univeral. After this experiment, we can evaluate this methodology compared to the current workflow.

=See Also=
*

=Useful Links=
*[https://www.youtube.com/watch?v=gShRBsahzXg A Youtube Video on USB's Recent Failure at Naming Standards Reflecting Change, and Making Sense]

Pieter log

2020-04-19T11:05:28Z

Pieter: /* Sunday 19 April 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}

= Sunday 19 April 2020 =

Added a proposal for [[Semantic Versioning]].

= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Improving Versioning

2020-04-19T10:56:05Z

Pieter: /* Proposal */

== Summary ==

* proposal to address issues with consistent versions of machines
* OSE's core business is actually producing documentation for machines available over a lifetime
* Good about the current situation
** proven technology, easy-to-use centralized wiki
** easy to use Google Presentations cloud application for build manuals
* Problems with the current situation
** wiki unstructured and overwhelming
** no real versioning in wiki and Google Presentations
** reliance on volatile, proprietary Google cloud services
** binary format for Google Presentations prevents proper versioning
* Requirements
# no major change in current workflow
# keep the wiki as central point
# do not rely on the wiki as a central point
# apply proper versioning reflecting severity of change
# true consolidation of machines with lifetime releases
# versioning supporting modularity
# no reliance on proprietary software/cloud services
# support textual format as much as possible for universal versioning
# same ease-of-use as Google Presentations
# automatic index for machines, modules, projects on the wiki
* Proposal
** adopt semantic versioning
** adopt Git with submodules
** create lifetime releases with Zenodo or IPFS
** automatically generate wiki pages, build manuals from Git repositories
** find a way to use a textual format as an easy-to-use replacement for Google Presentations
* Concrete steps
** Investigate the above in the Hamburg STEAM Camp

== Introduction ==
Several projects in OSE become viable products, for example the D3D Universal and D3D Pro are being sold as kits. However, the nature of OSE is that many projects are in a high rate of development and versions may change much in a short amount of time. For example, the D3D Universal changed considerably from the summer of 2019 to January 2020 and possibly as a result the documentation on the wiki was not consistent.

On this page we will try to address some the issues. We will first elaborate on the context, then we will discuss what is good in the current situation. We will then define the problem and finally outline a set of ideas and requirement to improve on the status quo.

== Context ==
Many machines are reaching a state that makes them a viable product. For others to be able to use them, we need proper documentation that is consistent over versions. The machines are highly modular which means that some version of machine A uses some version of project B. If B advances, it may no longer be a fit to A. As such, it is necessary to maintain bookkeeping about which version of a different component is used.

We could ask ourselves what OSE's core business is. An acceptable answer would be producing the machines of the GVCS. However, a more refined answer would be that OSE produces documentation to build the machines of the GVCS. To be able to repair them, it is necessary to understand it, hence the documentation.

An interesting feature of the OSE machines is that they should be usable over a lifetime. However, this would also require for the documentation to be available over a lifetime. It is not clear whether that is guaranteed currently.

Another question is then: What does it mean that the machine is available over a lifetime? Is the machine (rather its documentation) built now available in 20 years? Is the documentation of that specific version available? The machines built now are versioned using year and month. Or is only the current documentation available of the machine in the current state?

== Qualities of the current situation ==
The current system in place has various good features. The OSE wiki has pages for each project where information and build manuals are stored. A wiki is proven method with a low entrance threshold for users. The wiki logs changes to the pages and people making the changes. Major benefits are:
* one central point of entry
* anyone can join
* ease of use
* logs activity with changes
* proven technology

Many of the build manuals are created in Google Presentations. This is a highly easy-to-use cloud application. Anyone can view the presentation and download it in various formats such as Microsoft Powerpoint, Libre Office, or PDF. It also supports templates to provide a fixed style and the application keeps track of versions although these versions are not available to the public as opposed to the wiki pages.

== Problem definition ==
Although there are certainly good things to say about the current situation, unfortunately it is also possible to name problems. One of the problems of the wiki is that it contains lots of information in a more or less unstructered way. Navigation is reliant on links between pages, there is machine information, firmwares, "meta" topics such as this, etc. A common complaint is that users find it hard to find their way and get overwhelmed with the content.

Although a wiki keeps track of changes, it is not really meant for versioning. To the best of my knowledge, it is not impossible to mark a page as being in a state that should be consolidated, for a machine release for example.

A problem with the way machines are versioned is that the version number does not reflect how severe a change is. Does a minor change lead to a new version number, for example a new Z-sensor on a 3D-printer? Perhaps it does, it may get version 20.04, but if next month the layout of the axes change, it may get version 20.05, whereas it is a major change. And 3D-printer 20.05 may make use of an improved universal axes but which version? Do we consistently change the 3D-printer version if the universal axis version number changes? Managing these version numbers requires lots of discipline in the current situation.

The build manuals are drafted in Google Presentations but this has drawbacks. Firstly, editing requires a Google account. Secondly, the application is a proprietary cloud application from a major company that has so many resources that they can build an extremely high quality cloud application. However, this results in high degree of [https://en.wikipedia.org/wiki/Vendor_lock-in vendor lock-in]. Google cloud services are highly volatile, see the [https://en.wikipedia.org/wiki/Google_Reader#Discontinuation discontinuation of Google Reader], [https://en.wikipedia.org/wiki/Google%2B Google +], and the number of video conferencing applications that may or may not be merged: Google Meet, Google DUO, Google Hangouts, Google chat, and all of these may or may not be integrated with Gmail. The point is that being reliant on such a large, volatile company where services may be canceled, terms of service may change is not a very "open" way of working.

More practical issues are the following: The internal format is not exposed to the user. The format is binary instead of textual which makes tracking changes more cumbersome and reliant on the used application.

== Requirements ==
Based on the current qualities and problems we can define a set of requirements:

=== 1) No major change in the status quo ===
The current way of working with the wiki has obvious benefits. Changing the way OSE works in a major way is likely to be unnecessary and a whole community has to make a big change.

=== 2) Keep the wiki as a central point ===
The wiki is a proven technology with a low entrance threshold. It brings a community together in a central place. However, central points have drawbacks, certainly in an open-source project.

=== 3) Do not rely on the wiki as a central point ===
The danger of a central point is that if the wiki goes offline, lots of very interesting information, a legacy, will be lost. It may be possible to protect for this.

=== 4) Apply proper versioning ===
A good approach would be to apply versioning in such a way that a version change reflects the severity of the change.

=== 5) Lifetime releases ===
True consolidation of versions in the form of releases (releases of the documentation) that will never be lost and available for eternity or at least for the lifetime of the machine.

=== 6) Versioning supporting modularity ===
The GVCS machines are highly modular. There should be a proper system in place that can keep track of the various version numbers of the sub-releases.

=== 7) No reliance on proprietary cloud services ===
For an open project as OSE, it would be preferable not to rely on proprietary software, also not on cloud services.

=== 8) Support textual format as much as possible ===
Proper versioning works best with textual formats. For versioning in binary formats one needs support from the application that produces the binary format, whereas versioning on textual formats can be done with any tool. This means that versioning becomes universal.

=== 9) Google Presentations ease-of-use ===
For documentation of the machines, the build manuals, we would like to have the same ease-of-use as Google Presentations offers.

=== 10) Automatic indexing ===
For the machines, the modules that are part of the machines it would be helpful if there were some form of automatic indexing. Essentially, it would be good to have more structure on the wiki.

== Proposal ==
If one agrees that an important objective of OSE is to produce documentation for building machines of the GVCS, then we can look at other fields that deal with structured information. In that case it makes sense to look at software engineering that already has a significant open-source initiative.

=== Semantic versioning ===
Typically, [https://semver.org/ semantic versioning] is used in the field of software engineering. With semantic versioning, a version number has three numbers, for example 2.3.4. With these three numbers one can convey how big a change is. For example from 2.x.x to 3.0.0 is a major change, from 2.3.x to 2.4.0 is a minor change, for example changing a z-sensor on a 3D-printer. A change from 2.3.4 to 2.3.5 is a very minor change, typically to solve a problem. An example is to replace an axis-stop with a new version that works better than the previous version.

This scheme is most dominant in software engineering and it may be wise to learn from it and adopt it. This would satisfy requirement 4.

=== Distributed versioning systems ===
Software engineering projecs typically use dedicated versioning systems. There are centralized versioning systems such as the old [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and the still used [https://en.wikipedia.org/wiki/Apache_Subversion SVN]. In these systems committing a change to the software registers the change on a central CVSor SVN server. This is not ideal for open source projects because if an open source project becomes less popular and someone decides to turn off the server, all version history is gone.

Therefore, more popular today are distributed versioning systems such as [https://en.wikipedia.org/wiki/Mercurial Mercurial] or [https://en.wikipedia.org/wiki/Git Git]. Especially Git is very popular. Distributed versioning systems work in a different way. Each user "clones" or receives a copy of the complete version history of the project. If a centralized repository is discontinued, any user can reignite the project. In addition, committing changes and registering these changes to a repository is decoupled.

An extra feature of for example git is submodules. A submodule is a Git repository inside a Git repository. The parent repository keeps track of a specific commit of a child repository. This mechanism can help us to keep track of modules, for example, version 1.0.0 of the D3D-Universal uses version 0.8.2 of the Universal Axis. Version 1.5.0 of the D3D-Universal however has changed to version 1.0.2 of the Universal Axis.

Git repositories typically have a ''master'' "branch", where a branch can be considered a chain of ''commits''. A commit is a change in the repository made by a user, for example fixing a typo, update a version number, or big changes such as removing many files. Many people can collaborate on a project by creating their own branch, for example 'add-second-z-axis', or 'fix-z-sensor-problem'. The people working on these branches commit in these branches and at some point they are ready and want to merge their branch into the master branch. This is essentially updating the master branch to add the new feature. The merge itself is also considered a commit. For example if both 'add-second-z-axis' and 'fix-z-sensor-problem' are ready and merged into master, the team could decide that this could become a new version. They can then 'tag' the current commit with the version number, for example 'v1.3.0'.

The benefit of Git is that people can collaborate in a structured way, it supports semantic versioning. The repositories are decentralized which means that losing the history of a project is unlikely. Adopting Git would satisfy requirements 6. It would help requirement 3 and 4. However, it may be a disruptive change opposing requirement 1.

=== Lifetime releases ===
There are multiple ways to satisfy requirement 5, lifetime releases. First, proper versioning (requirement 4) has to be established. One way to create releases for eternity is by using [https://zenodo.org/ Zenodo]. Zenodo is a project by CERN with funding from the European Union. It is a data repository using the infrastructure of the Large Hadron Collider. It allows you to take a snapshot of a Git repository and associate a unique [https://en.wikipedia.org/wiki/Digital_object_identifier DOI] to it. This basically ensures that releases will be around for eternity.

Another solution is to use the [https://ipfs.io/ InterPlanetary File System] where we can store and possibly 'pin' versions for eternity. This relies on having multiple copies of the versions hosted by different nodes in the network.

=== Generating wiki pages ===
As the benefit of the wiki is clear, we need some way of bringing all of the above together. A proposal is to move serious development of the machines to a dedicated Git repository, for example 'univeral-axis' and 'd3d-universal'. The Git repositories contain a LICENSE file, a README, a CONTRIBUTING, a Changelog file, a VERSION file, and a Makefile, just as in a open-source software project. The README explains how the repository works, for what machine the repository is, etc. The CONTRIBUTING file defines a set of guidelines to aid users in contributing content. The Makefile is essentially a script that keeps track of dependencies between files and 'builds' the project, we will come back to this later. The other files are self-explanatory.

The main content of the repository consists of documentation in textual format together with the CAD files of the project. With all this content we can 'build' the project which means in this situation that we generate documents for the machines. An example would be to 'make' the build manual or 'make' the wiki page of the project, or 'make' the BOM. The make script would ideally automatically generate images from the CAD files to be used in the documents that this project generates.

As such, we can generate a wiki page and add that to the wiki ensuring that the information on the wiki remains consistent. We could also automatically create an index for the wiki for several of these project, satisfying requirement 10.

Ideally, we could even try to support to automatically incorporate editing actions on the wiki page back into the git repository to make sure that regular users can still contribute in a user-friendly way.

Unfortunately, all of this, does not fully satisfy requirement 1. However, the benefits may outweigh the change. It does satisfy requirement 2 and because of the decentralized nature of Git repositories it satisfies requirement 3. Git is an extremely powerful tool but therefore also difficult to use. However, the basic required commands are easy to use and learn with proper documentation and tutorials. Therefore, the overall ease of use is diminished (requirement 9).

=== Textual format ===
To make this all work, it would be ideal if most of the content in the repository is textual since it helps keeping track of changes easily. Binary files increase the size of the repository (every new commit with a binary file increases the size of the repository with the size of the file) and it is impossible to see what change was made. Unfortunately FreeCAD files are also binary, but because it is essentially a ZIP file, we could make Git a bit smarter to allow proper versioning on these files as well.

To satisfy requirement 7, moving away from Google while maintaining the same ease-of-use (requirement 9) together with supporting a textual format (requirement 8) is an open question. One could think of using the [https://en.wikipedia.org/wiki/Markdown Markdown] format in combination with [https://pandoc.org/ Pandoc] to convert it to various other formats. Another option is [https://orgmode.org/ Org mode] that has excellent integration with the [https://www.gnu.org/software/emacs/ Emacs] editor.

== Concrete Steps ==
A proposal is to investigate all of this as part of the STEAM Camp Hamburg. A good use case is to apply the above methodology to the D3D-Univeral. After this experiment, we can evaluate this methodology compared to the current workflow.

Improving Versioning

2020-04-19T10:54:03Z

Pieter: /* Requirements */

Improving Versioning

2020-04-19T10:51:48Z

Pieter: /* Problem definition */

Improving Versioning

2020-04-19T10:48:37Z

Pieter: /* Qualities of the current situation */

Improving Versioning

2020-04-19T10:47:40Z

Pieter: /* Intro */

Improving Versioning

2020-04-19T10:45:46Z

Pieter: Add a summary

= Summary =

* proposal to address issues with consistent versions of machines
* OSE's core business is actually producing documentation for machines available over a lifetime
* Good about the current situation
** proven technology, easy-to-use centralized wiki
** easy to use Google Presentations cloud application for build manuals
* Problems with the current situation
** wiki unstructured and overwhelming
** no real versioning in wiki and Google Presentations
** reliance on volatile, proprietary Google cloud services
** binary format for Google Presentations prevents proper versioning
* Requirements
# no major change in current workflow
# keep the wiki as central point
# do not rely on the wiki as a central point
# apply proper versioning reflecting severity of change
# true consolidation of machines with lifetime releases
# versioning supporting modularity
# no reliance on proprietary software/cloud services
# support textual format as much as possible for universal versioning
# same ease-of-use as Google Presentations
# automatic index for machines, modules, projects on the wiki
* Proposal
** adopt semantic versioning
** adopt Git with submodules
** create lifetime releases with Zenodo or IPFS
** automatically generate wiki pages, build manuals from Git repositories
** find a way to use a textual format as an easy-to-use replacement for Google Presentations
* Concrete steps
** Investigate the above in the Hamburg STEAM Camp

Pieter log

2020-04-14T18:33:41Z

Pieter: /* Sunday 12 April 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}
= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video. In discussion with Marcin about [[Teaching Module Requirements for STEAM Camps|requirements]] for video courses. Looks like a great list.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-04-14T18:24:38Z

Pieter: /* Sunday 12 April 2020 */

{{Hint|Please post your DIY arduino Pictures at [[DIY_Arduino]] or here}}
= Sunday 12 April 2020 =

Preparing KiCAD 101 video course. Thinking out the different modules. Learning the Kdenlive program. Making a list of things to order. Record a couple of clips to try out. Thinking about handouts that should go with the video.

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-04-05T18:54:33Z

Pieter: /* Sunday 29 March 2020 */

= Sunday 5 April 2020 =

Added missing files to the log as was suggested by Marcin. Investigated how to do a proper KiCAD tutorial with an Arduino. I realized I don't have a good video camera, so I looked into how to make the Raspberry Pi Tablet from the 2020 January STEAM Camp. I was hoping to build the tablet in a day or so, but as I understand it is still in a high state of development, so it probably won't help me with a video camera. I could make a stand for my phone which would actually be a good FreeCAD exercise.

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-04-05T09:04:04Z

Pieter: /* Sunday 2 February 2020 */

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

As per the hint, the KiCAD project for the stripboard Arduino is: [[File:Kicad-project-stripboard-arduino.tar.gz]]. From this file the following pdfs were created:
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

File:Kicad-project-stripboard-arduino.tar.gz

2020-04-05T09:00:44Z

Pieter: A KiCAD project for a stripboard Arduino. Note that this was created with KiCAD 5.1.5 which cannot be opened with the KiCAD version of OSE Linux.

A KiCAD project for a stripboard Arduino. Note that this was created with KiCAD 5.1.5 which cannot be opened with the KiCAD version of OSE Linux.

Pieter log

2020-04-05T08:52:48Z

Pieter: /* Saturday 1 February 2020, add files on which we were working */

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

For reference, as per the hint, the files are:
* [[File:Dimmer.tar.gz]]
* [[File:flatcam-dimmer.tar.gz]]

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

File:Flatcam-dimmer.tar.gz

2020-04-05T08:51:55Z

Pieter: Output from the Dimmer KiCAD project that was used in FlatCAM to create isolation routing gcode. The SVG files are also included.

Output from the Dimmer KiCAD project that was used in FlatCAM to create isolation routing gcode. The SVG files are also included.

Pieter log

2020-03-29T14:11:56Z

Pieter: /* Sunday 29 March 2020 */

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

== Collaboration Open Source Software Projects ==
At one of Marcin's presentations at the CEB Microhouse Build in Belize, he
mentioned that many open source software projects show little collaboration. I
agree with that but I want to share my view on that given my (actually not so
extensive) experience on contributing to open source software.

=== Summary: ===
* Software is very complex limiting collaboration. A good metaphor for understanding the complexity of contributing to a software project: it is like learning a new language.
* An interesting way to solve this is put forward by Pieter Hintjens (name and location of the presentation (the Netherlands) are a coincidence, the speaker is Belgian). These ideas may be interesting to OSE as well:
** [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]
Below you can find a more detailed summary of the talk, but this is these are the main brief takeaways:

There are four rules to build an open source community:

# Put people before code
# Make progress before agreement
# Problems before solutions
# Contracts before internals

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. We can do this by collaborating and embracing failure.

=== Full text ===
I believe an important reason why many open source software projects show
limited collaboration is not that people do not want to contribute but that the
software is so complex that it is very difficult to just jump in. My opinion
is that software in general is very complex. In essence, a software project is
a very high density piece of information with many different subtle connections
between many parts of the code where changing even one character can break
everything. Due to this enormous complexity it usually requires a serious
investment to contribute code.

The following is an example of how subtle the interactions in code can be. The
if-statement below checks whether something has some feature and based on this
feature it does something.

if has_feature_a {
do_something_with_a
}
else if has_feature_b {
do_something_with_b
}
else if has_feature_a AND has_feature_b {
do_something_entirely_different
}
else {
do_something_default
}

This looks like perfectly reasonable code, but careful examination shows you
that the order of if-statements has meaning here: to make it correct, the third
if-statement should move to the top because if something has feature a and b,
it also satisfies the check for having only feature a. I've seen this going
wrong even though there were explicit comments indicating that the order of
if-statements was relevant. These kinds of subtle interactions between pieces
of code make software very complex.

Another example to illustrate how complex software is, in this case when high
performance is required: Contributing to an FFT library for GPUs boiled down to
writing a program that generated many different constants and templates in the
form of code. These constants and templates would become the source files of
the FFT library. These source files would compile to the FFT library and
running the FFT library would compile binaries from the templates at run time
for the GPU that would then execute on the GPU.

Essentially, there is a program that creates a program that creates a program
for doing FFTs, so there are three level of indirections. The second program
was added to the source files of the FFT library, the first program was simply
discarded and the third program is generated on the fly by the FFT library. A
problem in the third program can have its origin in the first program,
something that may be very difficult to trace.

Software projects are usually written in a specific kind of programming
language. The idea is that if programmers know this programming language, they
can jump right in, but in my opinion that is almost never the case. Actually,
if a programming language is sufficiently expressive, it is possible to use the
programming language to create a new domain-specific language to express the
problem that a specific software project tries to solve. In my opinion
starting to collaborate on a software project can be compared to learning a new
language, a language to learn the problems that this software project tries to
solve. Perhaps, it is not so difficult as learning a spoken foreign language
but it provides a good frame of reference to understand the complexity of
contributing to a software project.

==== Building Open Source Communities ====
An interesting way to solve this is put forward by Pieter Hintjens (name and
location of the presentation (the Netherlands) are a coincidence, the speaker
is Belgian). These ideas may be interesting to OSE as well:

* [https://www.youtube.com/watch?v=uzxcILudFWM Building Open Source Communities]

A summary of the talk:

There are four rules to build an open source community:

# Put people before code If there are no contributors, the project is dead. People are much more important than the code.
# Make progress before agreement The approach is to not do code reviews but instead just merge a contribution even if it breaks everything. The reason is that reaching an agreement is too time consuming. Reaching agreement is a form of synchronization and synchronization limits parallelism which limits productivity.
# Problems before solutions An important question for a contribution is: What problem is it solving. If there is no clear answer, discard it.
# Contracts before internals First make how something should interface with something else, so think as much as possible in contracts. Licenses are a social contract for the community and share-alike patches are the most convenient because you never have to think about the license of a contribution.

There should be some rules, such as about coding style, how to patch, but more important is that an open project has one important rule:

* Anyone has the '''right''' to be a contributor

Often 'core maintainers' are the enemies of communities because they have power
to enforce rules. For the community it is much better that maintainers are not
special.

An interesting question and answer:

* How can we understand what a community wants?

We have to think of people as an ant colony that is more intelligent as a whole
than the sum of the individual ants. By itself, an ant is lost and so is a
human. We have to put aside egos and work more together like an ant colony
does, essentially embracing failure.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

User talk:Eric

2020-03-29T09:15:35Z

Pieter: Message for Eric

'''Welcome to ''Open Source Ecology''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Marcin|Marcin]] ([[User talk:Marcin|talk]]) 08:45, 20 October 2017 (CEST)

----

Eric, I've been following your wiki contributions, really interesting stuff, thank you for contributing.

Just a few minor suggestions, I noticed you don't use the wiki markup very much, particularly two features:

# numbered lists
# signature tag when doing discussions

For numbered lists put a hash mark in front of items, instead of manually numbering things (edit this talk page to see how I did the list above).

For tagging your comments in talk pages there is a button above the textarea (second from the end) with help text reading: "Your signature with timestamp". If you click that it will automatically insert some characters that get replaced with your name, date, etc upon saving the changes.

Definitely take some time to read the markup help pages, there is a lot of cool stuff you can do with wiki markup: https://www.mediawiki.org/wiki/Help:Formatting

Thanks and have fun! --[[User:Lex Berezhny|Lex Berezhny]] ([[User talk:Lex Berezhny|talk]]) 23:44, 15 November 2017 (CET)

----

Lex, Thank You!

I am definitely still a novice in this whole text/webpage/wikipage formatting thing so your help is greatly appreciated!

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 06:45, 16 November 2017 (CET)

----

We are in OSE meeting now, you should join if you can:

https://meet.jit.si/OpenSourceEcology

--[[User:Lex Berezhny|Lex Berezhny]] ([[User talk:Lex Berezhny|talk]]) 21:01, 21 November 2017 (CET)

----

Im writing this as a template for myself.

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 22:48, 24 Febuary 2017 (UTC)

----

== wiki work ==

great work on the wiki Eric. if you are looking for a little project you could go through and make sure that each of these genealogy pages are listed in order of newest to oldest [[Genealogy_Directory]] Also might try to make them all styled with bullets or whatever the same way. Also, feel free to try out OpenSCAD if you want to jump in on the circular knitting machine code :D I can help with tips and tricks.
--[[User:Dorkmo|Dorkmo]] ([[User talk:Dorkmo|talk]]) 21:50, 10 March 2018 (CET)

----

Thanks! I can definetly do the organizational stuff. For now I am trying to make "Construction Sets" for just about everything we have made or will make. I am also doing some stuff like making sure all information pages go into a page similar to constructions ses but for knowledge. Organizing the geneologies fits nicely into this so I will definetly do that.

I am a student so my work is kind of sporadic. Once I am done with all the stuff listed in the above bit I will probably do a smaller design or to of mine on this page as a sort of learning exercise. I think I will do this [[Open Source Vacuum Cleaner]] project, or maybe design a dremel tool holder to make a basic [[D3D 3 Axis CNC Mill]].

Then once I am done with the above things I will probably join the official dev team and do stuff with that.

Anyhow how does OpenSCAD work? From what I gathered (and may be completely wrong in thinking) it is a CAD software where you directly interface with the code, instead of a program like FreeCAD where you use the interface of the software (unless you get all fancy in FreeCAD at least).

I don't think I will be of much help on that front (YET at least). Although, It seems like you are doing a fine job on it without me getting in there so I guess I will leave it at that. Sorry if I ranted a bit there, and keep up the great work!

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 01:14, 10 March 2018 (UTC)

----
I'm just writing this as a sort of test of this f a n c y n e w s e r v e r before I do anything else.

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 01:10, 24 May 2018 (UTC)

----

I'm Back!

Had some health related stuff to deal with, but i'm good to go now. I'm going to start by reading through the changelogs and watching the meetings, but hopefully I will be caught up soon!

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 12:38, 17 November 2018 (UTC)

----

Happy New Year!

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 22:57, 1 January 2019 (UTC)

----

Hi Eric, thanks for offering to help get materials together for expo events. I would most appreciate help getting together a few signs/displays and information sheets, mainly I need the graphics/documents. I would like to get an Open Source Ecology sign and a display of the 50 machines of GVCS, with a high quality graphic I can get these printed. A hand out for at least the D3D would also be good for tabling. I added some sections https://wiki.opensourceecology.org/wiki/OSE_Participation_in_Makerfaires#Tabling_supplies
and if you can collect good graphics that would be super helpful.

[[User:Poli|Poli]] ([[User talk:Poli|talk]]) 03:03, 7 February 2019 (UTC)

----

Have a long weekend at last, so I'm diving into these posters. With the 50 Machines, some of them are very outdated looking (ie the 3D Printer looks like the original reprap, not the D3D). Should I correct this? Everything else is going nicely.

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 21:57, 18 January 2019 (UTC)

----
I ordered a poster already, so that is set. It is just a sign so people have an organization name, I used this image http://www.sharingame.org/media/Global_Village_Construction_Set-1024x712.jpg . I am trying to get together a few explanation graphics to lead people through the concepts required to understanding how a 3D printer works.
https://wiki.opensourceecology.org/wiki/D3D_Enterprise_Training_Program#Curriculum_for_education

So a figure showing how xyz coordinates are used in making 3D models and generating gcode is my next deliverable

[[User:Poli|Poli]] ([[User talk:Poli|talk]]) 02:58, 19 February 2019 (UTC)

----

== circular knitic ==

lol yeah! re: the arduino shields, it is very silly and expensive use of materials, but its working for now, woot. i'll upload a picture later for the lulz
-Poli

I want liquid helium and a black market nuclear Turbo-electric submarine next...
--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 3:35, 2 March 2019 (UTC)

----

Just got back from a talk at UNF with my school's "Great Decisions" club. The guest speakers were James Fallowss and Deborah Fallows. They spoke about their book "Our Towns". This book explores troubled cities in the USA, but also how those same cities came back. There are a lot of similarities in philosophy, as well as some potentially useful ideas/methods in it. All in all it was a great speach, and I will now try to get some of it's bullet points down, and possibly find a reccording of it (They have broadcasts, but I don't know if it is private etc).

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 00:56, 9 April 2019 (UTC)

----

Just got settled in for my first semester (summer B) of University at the University of North Florida (or UNF). Tommorow my classes start, but I will try to send an inquiry about using the schools fab-lab for OSE work (I toured it a few years back; pretty extensive, although I will probably stick to the welder, hand torch, and their 3D Printer, as their industral Multi Axis CNC is way too expensive and important for my needs as of now. I will try to keep everyone updated about all this excitment! (PS I also got a laptop with some REAL processing power for University + Immediately Afterwards, Huge improvement in render times, which is refreshing, I may also try a dual boot Windows+OSE Linux later)

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 22:19, 23 June 2019 (UTC)

----

Just got signed up for the Personal Protective Equipment mini-course/quiz needed to gain acess to UNF's Machine Shop Part of their Fab-Lab! I'll finish that after homework today or tomorrow, so I should be able to use it quite soon. Their FDM + Vaccuum Former Section did get moved, as I suspected, so that requires a different inquiry... Learning how to torch, turn, and weld components should keep me busy until then!

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) (14:44), (2) (July) (2019) (UTC)

----

FINALLY finished all of that Fab Lab Saftey Stuff, it was kind of on the back burner for a while. Projects need to get cleared and have some level of legitimacy/relivance to them in order to use the space (which is all okay, I was planning on only using machines stuff when they were not currently being used for full on engineering projects)

I may try and found an OSE club at UNF then. It would probably fallshort of being a full on OSE campus, but I can see some possible ways it could go:

*Open Source Golfcarts for Maitenence Staff Etc
*Open Source Power Tools for Maitenence Staff Etc
*Open Source Construction Vehicles for Construction and for Maitenence Staff Etc
*Open Source Bikes/Velomobiles for sale/rent
*UNF (3D) Print Service (As we already have UNF Printing for paper goods)
*We have an onsite garden that supplies the cafeteria today I will see if they would be intrested in anything, such as a micro trac, a greenhouse and/or aquaponics system, and maybe a D3D Farmbot
*Collaboration with local affordable housing groups like habitat for humanity with a CEB press and/or Open Source Power Tools, and/or Open Source Construction Vehicles
*Host a Makerfaire

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 13:10, 20 August 2019 (UTC)

----

So this past thursday, I was at a completgely different counterprotest against the schools soapbox preacher guy, and I met a computer science major. We struck up conversation, and I brought up OSE. They seemed intrested, and may join soon. They probaably have class today, I only have class monday through thursday. I will try to contact them later today or tomorrow to see if they are sttill intrested, and help them set up an account etc.

--[[User:Eric|Eric]] ([[User talk:Eric|talk]]) 12:53, 19 October 2019 (UTC)

----
Hi Eric,

As requested by Marcin, I consolidated the notes on marketing on various places, see my [[Pieter log#Notes on Marketing|notes on marketing]]. Looking forward to learn about your ideas.

--[[User:Pieter|Pieter]] ([[User talk:Pieter|talk]]) 09:14, 29 March 2020 (UTC)

Pieter log

2020-03-29T09:04:02Z

Pieter: /* Sunday 29 March 2020 */

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

== Notes on Marketing ==

Consolidated the notes on marketing below in:
*[[Marketing]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Target Audience for STEAM Camps

2020-03-29T09:03:15Z

Pieter: /* Intro */

=Intro=
We estimate the market size for relocalization towards circular economies to be around $30T, the size of the primary and secondary sectors of the economy (see [[Google Presentation]] for tipping point calculation towards a collaborative, open economy). As such, this affords the possibility of large scale collaboration towards transforming the economy towards open and collaborative, as in the [[OSE Vision]]. The [[Open Source Microfactory Mastermind]] would be a dedicated groups of open, collaborative developers who are interested in being owner-operators of enterprises in a local, circular economy. They collaborate globally, and have lofty ideals, and build locally so they don't sit on armchair theory.

Areas of OSE development include the [[Open Source Microfactory STEAM Camps]] for broadscale participation in collaborative design, the [[Summer of Extreme Design-Build]] focusing on larger-scale prototyping, and [[Incentive Challenges]] for [[Distributive Enterprise]] development.

For the STEAM Camps, we are recruiting instructors and marketing to participants. '''The working question is clear definition of the target audience.''' Here are some notes. Also see [[Marketing]].

=Open Source Microfactory Mastermind=
What we work on and how we work:
#We agree on a product roadmap
#Product strategy - we develop product strategy for each product
#Marketing strategy -
#Owner Operators - producers in local economies who move up in management over time
#Any investor is required to also be an operator until finalized production is defined
#Community not for community sake but for transformative movement entrepreneurship
#Teacher/builder/researcher. No basic research - applied product research for accountability to closed loop material cycles at the community scale
#Open source version of Fab City
#Collaborative version of Fab Academy
#People who envision common products being made in their own community, so that we reach the circular economy
#Distributed, open marketing templates, like Clickfunnels but open source and distributive
#Profile - disposable income higher than average. Looking for meaningful work with purpose. Sideline to full time. Interested in sharing knowledge. Has courage sufficient to share source code of economic value (product design, production engineering, product strategy, business plan). Is interested in ethical systems transformation without compromising to adapt to system (The Unreasonable Man) Understands societal critique without invoking victim mentality (They are out to get you. Who are 'They'?) See Juice Rap News 30.
#Possible profile - libre hacker ethical cooperator (distinct from supercooperators, who have no limits to working outside of their own cultural base)
#Possible profile - open-minded Fab shop owner who wants to diversify their range of services, but needs to learn more about open collarative protocols
#Possible profile - '''People with tech background but don't have hands-on skills. 20's or early 30s in tech sector. With motivation to have meaningful impact.'''
#Possible profile - ethical entrepreneur who questions structural evil and has a successful business that participates in [[Structural Evil]] to the least extent possible.
#Someone who is well versed in systems-based conceptualization of structural evil, and has the ambition to transform it more than the ambition to benefit from it. Has the wisdom to distinguish enterprise that can move the dial (ethical scalability), vs pursuing fringe movements that do not consider systems thinking or are violent in their nature.

=Growing an audience=

The target audience for the full OSE mission may be a very limited one. Instead, it may be wise to think in terms of wider audiences, such as people that are interested in how thinks work. For example, there is an interesting and popular YouTube channel that tries to understand how things work: [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything]. Focusing on such an audience and introduce them gradually to the principles of OSE may be a good approach. See the following [[Pieter log#Notes on Marketing|notes on marketing]].

=Targeting an audience on YouTube=

The following page describes how to target an audience on YouTube: [[YouTube#Targeting a specific audience|Targeting a specific audience]].

=Feedback - Don Jacobsmeyer=

You’ve articulated some of the “what”, you haven’t talked about the “who”. I’d encourage you to humanize this audience. Give one a name, talk about them by name. Let’s say Frank.

Frank has X skills and Y social interests. He’s fascinated by the potential for ABC but hasn’t come across a highly actionable model to take X + Y and create a small scale version of ABC. So instead he finds himself toiling away on DEF which just frustrates him further because there’s no self fulfillment in it.

Try to insert your other concepts in this narrative and see where it goes.

=Frank has X skills and Y interests...=

'''Please write down below something that describes your goals, motivations, and needs - and how OSE's STEAM Camps or [[Summer X 2020]] can meet those needs:'''

Profiles for different people:

'''#Jeremy''' - Entrepreneur with a major DIY mindset. I am looking for meaningful work that can impact society in a positive and ethical manner. I have a large amount of discretionary time available 6 months per year. I am interested in sharing knowledge, teaching and inspiring those around me with the incredible potential of OSE and Open Source Hardware. I want to broaden others' understanding of the world and to inspire young people with the myriad of possibilities that OSE projects/hardware makes available. I hope to establish a makerspace/microfactory locally through bootstrapping and partnerships in my community. The end goal is a self funding non-profit dedicated to advancing open source hardware development by involving and educating in the local community.

'''#Don''' -

'''#Randy''' - We hoard financial, material, and proprietary intellectual resources for financial gain. Knowledge, comfort, energy and wealth have been created from intense generational effort and investment. This benefited everyone somewhat. How can we best use our discretionary time, attention, material and financial resources and clever ideas? Entire continents lack even marginal shelter, food production, healthcare, water and power. Patent protection has attracted massive investment capital and innovators. Open Source invites collaboration and sharing instead of hiding and hoarding. It attracts a different group of participants. This initiative is not attempting to build a few essential devices. It aims to change the relative composition of users and producers in the local and worldwide economy for the benefit of all.

As a financial professional, mba, cpa, I have worked with established corporations, and a new company developing hydrogen energy and computer hardware and software. I co-founded a consulting company with clients such as United Technologies, GE Plastics, Cytec, Mississippi Chemical, Rubbermaid, and Chrysler. We observed and documented all manufacturing equipment. I helped re-write the Constitution of the State of Hawaii as an elected delegate in 1978. I have an MA in Curriculum & Development, and taught math in urban public middle and high schools. I love supporting the vision of Marcin, Catarina, and others I have met as we continue to iterate and improve Open Source documentation, devices, structures, events, and participants. If you examine a graph of exponential growth, for a long time it appears as though there is almost no growth. Suddenly growth explodes. Open Source will follow that curve. Open Source is practical, accessible, and inevitable.

'''#Vasco'''
-

'''#Ian''' - I'm a technologist and educator currently on the leadership team of a small charter-like high school. I am also the digital technology teacher at the school. I am passionate about equipping youth (specifically indigenous youth) with the tools to create their own career pathways, having the technical skills to solve real-world problems and ultimately building the future that them, their family and communities want. I believe the OSE has the right vision and skill to empower a generation of collaborative innovators on a global scale that together could achieve any level of self-determined aspirations.

'''#Daniel''' - I'd like to be able to build things. For myself, my family and friends, for my local community and for the wider society. Being able to build gives me an agency in the world that I am hungry for. It is a gateway to unleashed creativity, self-sufficiency and a more meaningful life.

I'd also like others to have the same opportunity. To get back in touch with their own creative power. To work together to actively solve the problems we face, rather than just tweet about it. Let's wake up and realise that the abundance we seek is within our grasp.

'''#Benoit''' - participant in [[Summer X 2020]] - I'm interested in learning how things work and being able to replicate without the help of any black box. Replication (can be called reinventing the wheel) is interesting because it validates your understanding and gives more autonomy - relying too much on the technology of a hyper-specialized civilization is a bit like believing in magic.

Also I enjoy it very much. So I got acquainted with some maths/algorithms, DIY signal processing, robotics, reverse eng, electronics; things that can be done in front a computer for the most part. At some point, interacting with the real world becomes necessary; with a limit set of resources and without a very broad set of skills it gets very difficult.

In order to build useful and interesting machines/processes and make this knowledge available, without jumping through so many hoops, I'm keen on learning manual skills, applied engineering and whatever else at the OSE STEAM Camp. Hopefully I'll also be useful with my less hardware oriented skills.

'''#Jessica''' - Jessica is an urbanist, designer, sculptor, and community catalyst. A licensed landscape architect,raised in the northern forests, trained in the legacy arts of stone carving and metallurgy, she understands the world as a continuum, and strives not to critique existing ''modus operandi'' but to replace them with something entirely new. She teaches ecological systems to architecture and landscape architecture students where an understanding of how the abiotc, biotic, built/ social, and disturbance patterns create the unevenness of space we experience becomes a tool for design from global to detail scales.

In her design practice that has taken her around the globe, she seeks models other than the traditional client and consultant roles to build, apply, and develop the most creative solutions imaginable to serve the community of ''place''. This has been the most challenging at home where progressive ideas are thrown around as political tactics and market forces are the rip tide to equity.

She has been looking for others who know what an engaged design process means and can do to empower a community. In need of collaborators and expertise in electronics and programming to develop she trusts her intuition about OSE STEAM Camp and intends to share her experience and provide training for others who are interested in making the collective the five legged bottom line.

'''#Mutton''' - Mutton is a movement entrepreneur interested in solving all of the world's most pressing grand challenges. He is fascinated by the potential of collaborative development, and thinks that all of the world's problems can be solved by first identifying them, and creating a school in which students work explicitly on tackling these problems. His mental model states that we must start at the level of how the world provides an economic basis for people - literally turning abundant dirt and twigs into the lifestuff of modern civilization.

He has been looking for a way to fund a school based on a promise of distributed, relocalized, circular economies, and has discovered that people are willing to pay for applied, hands-on, entrepreneurial education. But right now, Mutton is missing the organizational support to translate his vision to build his school. He further wants to have no investors who are not direct stakeholders (either students or teachers) in the school - making startup harder. He has found that finding such direct stakeholders is difficult, so he decided to join the OSE STEAM Camps program to find more aligned people, so he can staff the school that he wants and populate it with students.

'''#Jeff''' -

=Links=
*[[Target Audience Braindump]]
*Announcement for STEAM Camp instructors by [[Andreas Log]] - how do we vet that through the above? [https://docs.google.com/document/d/169v3knwWDK0OhecMQTPpzW6e-mVABCA82UOvMlfiqPk/edit#]

YouTube

2020-03-29T09:01:39Z

Pieter: /* Targeting a specific audience */

OSE YouTube channel is OpenSourceEcology: https://YouTube.com/user/OpenSourceEcology

== Adding Annotations and Links ==

[https://support.google.com/youtube/answer/6035690?rd=1 Google Support]

[[Category:Social Media]]

==Embedding Youtube in the Wiki==

<nowiki>

<html>
<iframe width="560" height="315" src="
https://www.youtube.com/embed/NWRtvaJ8iHo
" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen>
</iframe>
</html>

</nowiki>

==Targeting a specific audience==

This section discusses some ways that may help to target a specific audience on YouTube. For general information about target audiences, see [[Target Audience for STEAM Camps]].

For example, an audience that is aligned with OSE is the audience for the YouTube channel:

* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything]

A naive way to bring OSE under the attention of this audience is to create a description of an OSE YouTube video that aligns with the audience of How To Make Everything (HTME). Then if you add links in the description to these channels, people that view the OSE video may receive recommendations of HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending the OSE video to HTME audience.

However, this may not be very effective. Instead, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

Marketing

2020-03-29T08:56:24Z

Pieter: /* Details */

{{Organization}}

==Marketing==
A list of various [[OSE]] marketing related pages.

==Details==
'''Active'''
*[[TED Talk]]
*[[Brochure]]
*[[Kickstarter Publicity Plan]]
*[[Target Audience for STEAM Camps]]
*[[YouTube#Targeting a specific audience|Targeting a specific audience on YouTube]]

'''Message'''
*[[Core message]]
*[[:Category:Slides]]

'''Archive'''
*[[Marketing Strategy]]
*[[Marketing Distillations]]
*[[Marketing Research]]
*[[Marketing Materials]]
*[[GVCS Publicity Plan]]
*[[Marketing Archive]]
*[[Contacts]]
*[[Factor E Farm in 5 Minutes]]
*[[Marketing Brochure Old]]
*[[Supporting Information]]
*[[Key phrases]]
*[[Keywords]]
*[[Outreach 2010]]
*[[Talk:Marketing]]
*[[Distillations]]
*[[Publishing Guidelines]]

==See Also==
*[[Media]]
*[[Press]]
*[[Interviews]]
*[[Development Strategy]]
*[[:Category:Collaboration Discussions]]

*[http://en.wikipedia.org/wiki/Marketing Wikipedia:Marketing]

=Links=
*[[Marketing Operations Manual]]
*[[D3D Marketing]]

[[Category:Marketing]]
[[Category: PR]]

Target Audience for STEAM Camps

2020-03-29T08:53:49Z

Pieter: /* Growing an audience */

=Intro=
We estimate the market size for relocalization towards circular economies to be around $30T, the size of the primary and secondary sectors of the economy (see [[Google Presentation]] for tipping point calculation towards a collaborative, open economy). As such, this affords the possibility of large scale collaboration towards transforming the economy towards open and collaborative, as in the [[OSE Vision]]. The [[Open Source Microfactory Mastermind]] would be a dedicated groups of open, collaborative developers who are interested in being owner-operators of enterprises in a local, circular economy. They collaborate globally, and have lofty ideals, and build locally so they don't sit on armchair theory.

Areas of OSE development include the [[Open Source Microfactory STEAM Camps]] for broadscale participation in collaborative design, the [[Summer of Extreme Design-Build]] focusing on larger-scale prototyping, and [[Incentive Challenges]] for [[Distributive Enterprise]] development.

For the STEAM Camps, we are recruiting instructors and marketing to participants. '''The working question is clear definition of the target audience.''' Here are some notes.

=Open Source Microfactory Mastermind=
What we work on and how we work:
#We agree on a product roadmap
#Product strategy - we develop product strategy for each product
#Marketing strategy -
#Owner Operators - producers in local economies who move up in management over time
#Any investor is required to also be an operator until finalized production is defined
#Community not for community sake but for transformative movement entrepreneurship
#Teacher/builder/researcher. No basic research - applied product research for accountability to closed loop material cycles at the community scale
#Open source version of Fab City
#Collaborative version of Fab Academy
#People who envision common products being made in their own community, so that we reach the circular economy
#Distributed, open marketing templates, like Clickfunnels but open source and distributive
#Profile - disposable income higher than average. Looking for meaningful work with purpose. Sideline to full time. Interested in sharing knowledge. Has courage sufficient to share source code of economic value (product design, production engineering, product strategy, business plan). Is interested in ethical systems transformation without compromising to adapt to system (The Unreasonable Man) Understands societal critique without invoking victim mentality (They are out to get you. Who are 'They'?) See Juice Rap News 30.
#Possible profile - libre hacker ethical cooperator (distinct from supercooperators, who have no limits to working outside of their own cultural base)
#Possible profile - open-minded Fab shop owner who wants to diversify their range of services, but needs to learn more about open collarative protocols
#Possible profile - '''People with tech background but don't have hands-on skills. 20's or early 30s in tech sector. With motivation to have meaningful impact.'''
#Possible profile - ethical entrepreneur who questions structural evil and has a successful business that participates in [[Structural Evil]] to the least extent possible.
#Someone who is well versed in systems-based conceptualization of structural evil, and has the ambition to transform it more than the ambition to benefit from it. Has the wisdom to distinguish enterprise that can move the dial (ethical scalability), vs pursuing fringe movements that do not consider systems thinking or are violent in their nature.

=Growing an audience=

The target audience for the full OSE mission may be a very limited one. Instead, it may be wise to think in terms of wider audiences, such as people that are interested in how thinks work. For example, there is an interesting and popular YouTube channel that tries to understand how things work: [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything]. Focusing on such an audience and introduce them gradually to the principles of OSE may be a good approach. See the following [[Pieter log#Notes on Marketing|notes on marketing]].

=Targeting an audience on YouTube=

The following page describes how to target an audience on YouTube: [[YouTube#Targeting a specific audience|Targeting a specific audience]].

=Feedback - Don Jacobsmeyer=

You’ve articulated some of the “what”, you haven’t talked about the “who”. I’d encourage you to humanize this audience. Give one a name, talk about them by name. Let’s say Frank.

Frank has X skills and Y social interests. He’s fascinated by the potential for ABC but hasn’t come across a highly actionable model to take X + Y and create a small scale version of ABC. So instead he finds himself toiling away on DEF which just frustrates him further because there’s no self fulfillment in it.

Try to insert your other concepts in this narrative and see where it goes.

=Frank has X skills and Y interests...=

'''Please write down below something that describes your goals, motivations, and needs - and how OSE's STEAM Camps or [[Summer X 2020]] can meet those needs:'''

Profiles for different people:

'''#Jeremy''' - Entrepreneur with a major DIY mindset. I am looking for meaningful work that can impact society in a positive and ethical manner. I have a large amount of discretionary time available 6 months per year. I am interested in sharing knowledge, teaching and inspiring those around me with the incredible potential of OSE and Open Source Hardware. I want to broaden others' understanding of the world and to inspire young people with the myriad of possibilities that OSE projects/hardware makes available. I hope to establish a makerspace/microfactory locally through bootstrapping and partnerships in my community. The end goal is a self funding non-profit dedicated to advancing open source hardware development by involving and educating in the local community.

'''#Don''' -

'''#Randy''' - We hoard financial, material, and proprietary intellectual resources for financial gain. Knowledge, comfort, energy and wealth have been created from intense generational effort and investment. This benefited everyone somewhat. How can we best use our discretionary time, attention, material and financial resources and clever ideas? Entire continents lack even marginal shelter, food production, healthcare, water and power. Patent protection has attracted massive investment capital and innovators. Open Source invites collaboration and sharing instead of hiding and hoarding. It attracts a different group of participants. This initiative is not attempting to build a few essential devices. It aims to change the relative composition of users and producers in the local and worldwide economy for the benefit of all.

As a financial professional, mba, cpa, I have worked with established corporations, and a new company developing hydrogen energy and computer hardware and software. I co-founded a consulting company with clients such as United Technologies, GE Plastics, Cytec, Mississippi Chemical, Rubbermaid, and Chrysler. We observed and documented all manufacturing equipment. I helped re-write the Constitution of the State of Hawaii as an elected delegate in 1978. I have an MA in Curriculum & Development, and taught math in urban public middle and high schools. I love supporting the vision of Marcin, Catarina, and others I have met as we continue to iterate and improve Open Source documentation, devices, structures, events, and participants. If you examine a graph of exponential growth, for a long time it appears as though there is almost no growth. Suddenly growth explodes. Open Source will follow that curve. Open Source is practical, accessible, and inevitable.

'''#Vasco'''
-

'''#Ian''' - I'm a technologist and educator currently on the leadership team of a small charter-like high school. I am also the digital technology teacher at the school. I am passionate about equipping youth (specifically indigenous youth) with the tools to create their own career pathways, having the technical skills to solve real-world problems and ultimately building the future that them, their family and communities want. I believe the OSE has the right vision and skill to empower a generation of collaborative innovators on a global scale that together could achieve any level of self-determined aspirations.

'''#Daniel''' - I'd like to be able to build things. For myself, my family and friends, for my local community and for the wider society. Being able to build gives me an agency in the world that I am hungry for. It is a gateway to unleashed creativity, self-sufficiency and a more meaningful life.

I'd also like others to have the same opportunity. To get back in touch with their own creative power. To work together to actively solve the problems we face, rather than just tweet about it. Let's wake up and realise that the abundance we seek is within our grasp.

'''#Benoit''' - participant in [[Summer X 2020]] - I'm interested in learning how things work and being able to replicate without the help of any black box. Replication (can be called reinventing the wheel) is interesting because it validates your understanding and gives more autonomy - relying too much on the technology of a hyper-specialized civilization is a bit like believing in magic.

Also I enjoy it very much. So I got acquainted with some maths/algorithms, DIY signal processing, robotics, reverse eng, electronics; things that can be done in front a computer for the most part. At some point, interacting with the real world becomes necessary; with a limit set of resources and without a very broad set of skills it gets very difficult.

In order to build useful and interesting machines/processes and make this knowledge available, without jumping through so many hoops, I'm keen on learning manual skills, applied engineering and whatever else at the OSE STEAM Camp. Hopefully I'll also be useful with my less hardware oriented skills.

'''#Jessica''' - Jessica is an urbanist, designer, sculptor, and community catalyst. A licensed landscape architect,raised in the northern forests, trained in the legacy arts of stone carving and metallurgy, she understands the world as a continuum, and strives not to critique existing ''modus operandi'' but to replace them with something entirely new. She teaches ecological systems to architecture and landscape architecture students where an understanding of how the abiotc, biotic, built/ social, and disturbance patterns create the unevenness of space we experience becomes a tool for design from global to detail scales.

In her design practice that has taken her around the globe, she seeks models other than the traditional client and consultant roles to build, apply, and develop the most creative solutions imaginable to serve the community of ''place''. This has been the most challenging at home where progressive ideas are thrown around as political tactics and market forces are the rip tide to equity.

She has been looking for others who know what an engaged design process means and can do to empower a community. In need of collaborators and expertise in electronics and programming to develop she trusts her intuition about OSE STEAM Camp and intends to share her experience and provide training for others who are interested in making the collective the five legged bottom line.

'''#Mutton''' - Mutton is a movement entrepreneur interested in solving all of the world's most pressing grand challenges. He is fascinated by the potential of collaborative development, and thinks that all of the world's problems can be solved by first identifying them, and creating a school in which students work explicitly on tackling these problems. His mental model states that we must start at the level of how the world provides an economic basis for people - literally turning abundant dirt and twigs into the lifestuff of modern civilization.

He has been looking for a way to fund a school based on a promise of distributed, relocalized, circular economies, and has discovered that people are willing to pay for applied, hands-on, entrepreneurial education. But right now, Mutton is missing the organizational support to translate his vision to build his school. He further wants to have no investors who are not direct stakeholders (either students or teachers) in the school - making startup harder. He has found that finding such direct stakeholders is difficult, so he decided to join the OSE STEAM Camps program to find more aligned people, so he can staff the school that he wants and populate it with students.

'''#Jeff''' -

=Links=
*[[Target Audience Braindump]]
*Announcement for STEAM Camp instructors by [[Andreas Log]] - how do we vet that through the above? [https://docs.google.com/document/d/169v3knwWDK0OhecMQTPpzW6e-mVABCA82UOvMlfiqPk/edit#]

YouTube

2020-03-29T08:43:10Z

Pieter: Targeting a specific audience

OSE YouTube channel is OpenSourceEcology: https://YouTube.com/user/OpenSourceEcology

== Adding Annotations and Links ==

[https://support.google.com/youtube/answer/6035690?rd=1 Google Support]

[[Category:Social Media]]

==Embedding Youtube in the Wiki==

<nowiki>

<html>
<iframe width="560" height="315" src="
https://www.youtube.com/embed/NWRtvaJ8iHo
" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen>
</iframe>
</html>

</nowiki>

==Targeting a specific audience==

This section discusses some ways that may help to target a specific audience. For example, an audience that is aligned with OSE is the audience for the YouTube channel:

* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything]

A naive way to bring OSE under the attention of this audience is to create a description of an OSE YouTube video that aligns with the audience of How To Make Everything (HTME). Then if you add links in the description to these channels, people that view the OSE video may receive recommendations of HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending the OSE video to HTME audience.

However, this may not be very effective. Instead, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

Pieter log

2020-03-29T08:07:47Z

Pieter: /* Sunday 29 March 2020 */

= Sunday 29 March 2020=

== CEB Microhouse Build in Belize ==

Another idea we developed during the Belize workshop is to have a Gantt chart available of all the steps. This would show you the dependencies between all the tasks, what can be done in parallel, how many teams you need to have, etc. To create this, we would need open source project planning software.

= Sunday 22 March 2020=

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Pieter log

2020-03-22T20:22:39Z

Pieter: /* Saturday 22 March 2020 */

= Sunday 22 March =

== Suggestions ==

Adding more feedback forms to the wiki:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]

== Maintaining the log ==

Maintaining this log based on all my written notes.

== Notes on Marketing ==

I've been discussing marketing with Brett and Marcin on Thursday 26 February on the bus ride from Copper Bank to Belize City. After having thought of this topic a bit, I came to the conclusion that I strongly believe that the full mission of OSE only appeals to a small group of people resulting in a small market. It does not mean that the full mission is bad, it is just that I think many people are not yet ready for the full extent of the OSE ideas.

However, I notice a trend towards using less of modern technology and towards more primitive technology, for example: traditional carpentry with hand tools, traditional barbers, etc. This is something that appeals to me too and I have the feeling that for many people, life has become a bit too technological in the sense that we cannot understand it anymore. Current technology almost seems too complex for people to handle and it seems that people want to either move back to something they can understand or that they want to understand current technology.

I believe these people form a far larger market and if you try to appeal to just the interest of understanding technology you might capture a far greater audience.

Examples of YouTube channels that tap into this interest are:

* [https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA Primitive Technology], a very fundamental approach to understanding technology
* [https://www.youtube.com/watch?v=kNp0HETeq6M&list=PLLXfVEsLI-qRC_MAQZcVxpjtF7I1-H6Gw How To Make Everything], a more pragmatic approach that recently started from the Stone Age to now

These channels have lots of viewers and I'm sure that many of them would be interested in understanding 3D-printers, understanding how to make your own PCB, understanding a light dimmer, making your own tablet, etc.

In a sense what I'm proposing is to "grow our audience". First we have to capture a larger audience that is open to understanding more of technology. The two channels above show that there is a large audience for that. After that, this audience can become aware of the bigger picture that OSE puts forward, namely that our lack of understanding leads to unfair competition, monopoly and an imbalance between people. Actually, the current Corona crisis accentuates the current problem where we lack understanding of how ventilators work and of how many of them we need. The following interesting article discusses that we don't know anymore how ventilators work, now that we really need them:

https://www.vice.com/en_us/article/wxekgx/hospitals-need-to-repair-ventilators-manufacturers-are-making-that-impossible

This article is an opportunity to show why we need OSE, perhaps we could contact the author to tell them that OSE works on an alternative economy where we wouldn't have these kinds of problems.

Concretely my thoughts on capturing this greater audience are as follows:

My initial, probably naive, guess was that you create a description of the YouTube video that aligns with the audiences of for example Primitive Technology (PT) or How To Make Everything (HTME). Then if you add links in the description to these channels, people that view your video will start viewing the PT video or HTME videos. Hopefully, YouTube's recommendation algorithm picks that up and reverses the relation and starts recommending your video to the PT or HTME audience.

However, the following links are probably much better in providing insight in how to target a specific audience:

* https://de.slideshare.net/AlexanderRus/how-to-rank-videos-on-youtube-and-in-google-search
* https://backlinko.com/how-to-rank-youtube-videos

= Saturday 7 March 2020 =

Transcribing the forms with suggestions for the CEB Microhouse Build in Belize and consolidating them:

* [[Transcription Suggestions CEB Microhouse Build in Belize]]
* [[Consolidation Suggestions CEB Microhouse Build in Belize]]

=Wednesday 26 February 2020=

== CEB Microhouse Build in Belize, Day 5 ==

Parallelism was kind of gone. Luke was mainly the lead in attaching the purlins. After lunch I helped attaching the purlins and helped lift up the metal sheets. The metal sheets were attached with screws with a rubber attachment to prevent water leaking through.

During conversation with various people I've received quite some references to things that I should check out:

* Projects
** [https://en.wikipedia.org/wiki/GravityLight Gravity Light]
* Movies
** [https://en.wikipedia.org/wiki/Force_Majeure_(film) Force Majeure (2014)]
** [https://en.wikipedia.org/wiki/Equilibrium_%28film%29 Equilibrium (2002)]
* Books
** The Zero Marginal Cost Society - Jeremy Rifkin
** Lo-TEK: Design by Radical Indigenism - Julia Watson

I've also recommended many people to read the following book:

* Factfulness - Hans Rosling
* [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Hans Rosling TED talk]

The book explains that the world is still a bad place but that it is much better than you think. The title is a play on mindfulness and tries to bring you calmness with facts. Being in Belize was very insightful after having read this book. Belize is clearly a "level 3" country where the daily income is around $16 and many people can afford a car.

=Tuesday 25 February 2020=

== CEB Microhouse Build in Belize, Day 4 ==

Instead of carpentry I decided that I wanted to learn stucco. Dustin showed a technique where you hold the hawk diagonally toward the wall and use the trowel to smear the stucco upwards on the wall. Ultimately, I preferred Ethan's method. Ethan explained that stucco stuck well to the wooden hawk but that it slid of the trowel because it was magnesium. Ideally you want that to be more sticky as well. You then smear it on with quite some pressure. We had a good working method with two people applying the stucco and one person feeding the stucco onto the hawks of the two other ones.

In the end of the day parallelism was kind of gone. The trusses needed to be put up. This was quite dangerous because they were very heavy. With Scott I planned on how to back up the trailer and asked Gaby if she or Aidan could back it up. In the end we decided that it was probably faster to carry the trusses and that's what we did. We lifted four of the five trusses up the house and attached them. Unfortunately something went wrong with the communication and the trusses were placed flush with the back wall, discarding the planned overlap of 2.5 and 1.5 inches on front and back. Another thing that went wrong was that the j hooks sticking out of the bond beam were too close to the edge. Because of this, we needed to chisel out part of the horizontal beam of the trusses to make place for the large bolts on top of the wood on top of the bond beam.

=Monday 24 February 2020=

== CEB Microhouse Build in Belize, Day 3 ==

I wanted to do some carpentry but before that we had to come-up with a plan for the wire mesh on top of the wall. On top of the wall we would pour the concrete for the bond beam and it would be best if the wire mesh would be inside the bond beam. At first, the idea was to find stones with a similar height and put the wire mesh on top of those stones. We would make two rows of these stones and the wire mesh would be on top of it. Rebar could go on top of the wire mesh. However, the frame of the bond beam was created with wooden cross-bars that would lie on top of the blocks. Having a heightened piece of wire mesh would disallow the wooden cross-bars to be on top of the blocks creating gaps from which the concrete would escape. The solution was to remove the stones underneath the wire mesh, put the frame with the wooden cross-bars on top of wire mesh, put the rebar on top of the wooden cross-bars and lift the wire mesh as much as possible by tying it to the rebar. A big drawback of this approach is that once the concrete is poured in, the wooden cross-bars are still inside the concrete and at some point they may rot and start smelling. This was not an ideal situation.

For the carpentry I worked with Brett, Jamie, and Nathan to create eight trusses. We found out that the wood was very unevenly cut, making this more difficult than necessary. The wood was very hard and heavy and because of this we deviated from the plan by putting the vertical beam and the diagonal beam on top of the horizontal one instead of side-mounting the diagonal and vertical beam to the bottom one. The reasoning was that the diagonal and vertical beam would rest on the horizontal one. We had lots of discussions on the design, on how to deal with the uneven wood, and on what measurements to use. We decided to have 1.5 inch overhang on the back and 2.5 inch on the front. Because of all the discussions and the decisions to make we only had three done in the end of the day.

Getting the nails into the wood was more difficult than expected. We tried three techniques: pre-drilling holes, pre-screwing, and just hammering in the nails. All was kind of the same. What made a real difference was lubricating the nails with old motor oil.

=Sunday 23 February 2020=

== CEB Microhouse Build in Belize, Day 2 ==

Finishing the walls first. We then worked on the safety net. The frame of the door already contained a piece of chicken wire. The goal was to attach the roll of chicken wire to this piece of chicken wire and attach it to the strands of wire sticking out of the wall. The foundation had pieces of metal sheet with holes sticking out on the inside and outside. The chicken wire needed to attached to this as well. Tying the chicken wire to the bottom metal, the door and window frames, and to the wires sticking out of the wall was very labor intensive. We also used staples to nail the chicken wire to the wall. Later, we learned that the spacing between the chicken wire and the wall is important for the stucco. I wasn't aware that the chicken wire had 2 functions. Essentially, we worked on this all day but couldn't get it finished.

In the end of the day I helped out pouring concrete on top of the door. There was a frame for the concrete to be poured in, the frame contained rebar and the J hooks. We used a chain of people to transport the concrete to the frame, poured it in, and 'stirred' it to get the air out.

= Saturday 22 February 2020 =

== CEB Microhouse Build in Belize, Day 1 ==

The first day of the CEB Microhouse Build in Belize. We first listened to an introduction by Marcin. We then visited the site and started the work. The main task of today was building up the walls by laying bricks. There were three kinds of bricks: unstabilized, 5% stabilization, and 10% stabilization. We called the 10% stabilized blocks as such, but in actuality they were 8% stabilization. The stabilization was done by mixing Portland concrete. Besides these three variants, there was a pile of thin bricks for the floor. In the pile of regular blocks there were thicker and thinner ones with which we could fill up gaps. The first task was to figure out which bricks had to go where. The four walls needed the bottom to be the most stabilized ones, so we were setting up block chains (a chain of persons handing over blocks) to distribute them to the four walls.

After the slurry was made, we applied what we called the "drip-and-rip" technique: We dipped the block in slurry and laid them out. We used a board on the back side of the wall (the inside of the house) to ensure a straight wall. A problem with this set up was that the board needed to be lifted up for each row of bricks. The beams to which the board was screwed was the typical Belizean hardwood which resulted in screws with a botched head causing us unable to remove the board. We changed to a technique where would just rest the board on a screw and using an initial loose block to keep the board in place. This technique had the drawback that you have to pay attention that the board is in place when starting a new row. The benefit was that we didn't need to remove the screws on which the board rested. Every two layers we laid out two cross-winded wires for the earthquake safety net. We finished 75% of the wall.

A problem was that we couldn't control the height over the length of the wall. Walls became easily higher on one side due to the amount of slurry on that side. Another problem was the overlap between the various rows of blocks. It was very difficult to keep the overlap consistent and we would need to find thinner blocks all the time to maintain overlap. Perhaps a different pattern would have been better and stronger.

=Sunday 2 February 2020=

{{Hint|Please upload the KiCad file for the Arduino}}

Yesterday, we finalized setting up the printer to perform the milling. Today it is only a matter of running it.

Holger showed me some nice etched boards that he plotted with the Universal. Very impressive, but the quality is not good enough to really use. There are many things to fine-tune.

Unfortunately, the printer did not behave as expected. After going over the whole process again, fine-tuning the set up and the process, we still couldn't make it work. It turned out that the "Set home offsets" function did not behave as expected. What I want is to tell the printer that the current position of the head should be regarded home, so in our case (0, 150, 0). However, for some reason the Z-axis did not follow this and remained at the same height as before. This caused the drill to move into the board. We could actually see a nice cut going on. After several more experiments, we came to the conclusion that we can't make it work properly if this "Set home offsets" doesn't work: it would mean endless tuning and together with the motors releasing power at unexpected times, this would not work. To make this work, it is important to inspect the firmware and the meaning of "Set home offsets".

We finally made the Arduino work as expected using the schematic [[File:Schematic-arduino.pdf]]. We can press the reset button manually and then non-deterministically the board will reset.

Outlook for after the STEAM Camp. I will focus mainly on improving the Universal and then specifically on improving the print quality. I want to fine-tune and calibrate the printer such that it can print parts for a second Z-axis. After that, I want to improve the print-quality even further having more control over the positioning of the X-axis with the second Z-axis. After that, I want to print all parts with the Universal itself, bootstrapping the printer so to speak.

=Saturday 1 February 2020=

{{Hint|Thanks for uploading KiCad, SVG files, and tutorial. Please also upload your FlatCAM file, and Gcode (generated by Inkscape and FlatCam).}}

I've installed FlatCAM on Arch Linux, made sure that the already printed drill holder can hold the sensor (the hole was too small). I tried to make it bigger with a Dremel, but it was much easier to saw a gap that can be easily increased with a screwdriver. The holes for the nuts are also to small. We pressed them in with a heat gun. We connected the drill to 12V and it seems to work.

Experimenting with a workflow from KiCad/FlatCAM to G-Code. At first, we tried to apply it to the Arduino circuit, later we switched to the dimmer circuit that Holger was designing. Helped out finalizing this design.

In KiCad we export the back cupper layer of the circuit design to Gerber files. We open this in FlatCAM and for some reason the y-axis is negative. This will result in G-Code that the Universal cannot handle and this has to be rectified. In the Project tab there is now one layer turned on and therefore visualized (the checkbox turns it on). In addition, the layer is selected and this selected layer can be edited in tab "Selected". In the bottom part of this tab, we can adjust the negative y-axis problem by pressing "Offset auto". We can also move the circuit more to the center of the print bed by inserting values (60.0, 60.0) and press "Offset". I expected the Gerber files to be automatically mirrored for the back side, but this has to be done manually as well in section "Mirror".

Now that we have done this, we can apply isolation routing. It is wise to check the feasibility of the routing by inserting the right diameter of the tool to use. We used a 1.0 mm drill bit that was not completely stable at the tip, so the effective diameter is probably more than 1.0 mm. We can generate the isolation routing layer by choosing "Generate geometry".

This will show the routing in the color red and in the "Project" tab a new layer has been added with the suffix "_iso". Now that we defined the isolation layer, we are ready to create a CNC job with G-Code. We used the following values in "Create CNC Job":
* Cut Z: we haven't experimented with this value yet. The standard value of -0.002 seems very low.
* Travel Z: 4.0mm, the drill moves up 4 mm.
* Feed rate: 50, we let the drill move very slowly
* Tool dia: 1.0mm

When we press "Generate", we will get another layer with suffix "_cnc" that shows the path of the drill. From here, we generate GCode. We choose 30s for dwell and press "Export G-Code".

This G-Code needs to be adapted a bit to let it work properly with the universal:
* In the beginning, the statement "F 50.0" has to be changed to "G0 F50.0". We also move this a bit backward to make the first move of the head (in the air) faster.
* In the end, the statement G00 X0Y0 has to be replaced with G00 X0Y75 to make sure that the head does not move to 0, 0 that we don't have.
We can now load the G-Code to SD-card and prepare the Universal:

* Adjust the Z axis such that the drill is close to the print bed, 0.2 mm or so. Adjust the Z-sensor such that it switches on without the drill touching the print bed.
* Do auto home
* Do bed-leveling
* Do auto home again
* Move Z up and place the material to cut
* Move Z down with the drill just touching the surface
* Set home offsets
* Move Z up 4 mm

In the meantime I'm helping Unai to get the breadboard Arduino working. This turns out to be more difficult than thought. For some reason we cannot get it to work properly. We rewired everything to the specification [[File:Schematic-arduino.pdf]] but we ran out of time to really try.

=Friday 31 January 2020=

Found out that I used the front copper wires in KiCad instead the back copper wires. I adjusted all lines.

Found out how to create an SVG that we can use with the gcode exporter in InkScape. Instead of plot, we do File -> Export SVG.

To create a decent SVG that can be used for edging, we select the back copper layer, select Black and White, Current page size (which should be 150x150mm to make sure we can align the drill holes), and Print Mirrored.

The KiCad files of the Arduino board with a small tutorial: [[File:Arduino-project-build-arduino.tar.gz]]

We are trying to create an outline of the copper paths to try to mill away the copper with the drill. Michel is manually editing the SVG file as we cannot find a good way to do this automatically, again because of the poor quality of the KiCad svg.

We found a way to get a clean SVG for generating gcode:
* In KiCad, we remember the track width that we chose (0.5 mm)
* We choose plot and plot the B.Cu layer in SVG format and mirror it with a default line width of 0.5 mm.
* Load the file in Inkscape
* Select all with C-a and ungroup everything with C-S-g
* Do Path -> Stroke to Path
* Enable a stroke and make everything black
* The width in stroke style is 100%, we make that 0.5 mm by first choosing mm as the unit and then set the value to 0.5.
* Disable the fill.

Berber had a much better way:

Lines and circles may be different, so treat them differently
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Stroke Color (This works because all the other components only have fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* Group these with C-g
* We give them a stroke of 0.5mm in Stroke style. Take away the fill to get a nice circle.
* To generate gcode it is necessary to ungroup everything (C-S-g).

Actually, the above method still doesn't work. We need objects that do not have fill and only stroke:
* Select all and ungroup multiple times
* Select a line, it will have a fill and a stroke
* Select all lines by Edit -> Select Same -> Fill and Stroke
* Convert them to only having a stroke by disabling the fill
* Group them with C-g
* Select one circle with this weird endcaps
* Select all of them with Edit -> Select Same -> Fill Color (this works because all the other components have no fill)
* Convert them to only having a fill by doing Path -> Stroke to Path
* We give them a stroke and disable the fill.
* We give them a stroke of 0.5mm in Stroke style by first selecting mm and then give the value 0.5
* To generate gcode it is necessary to ungroup everything (C-S-g).

Converting this to an outline can be done in the following way:
* Select all, and ungroup
* C-k to combine
* Path -> Stroke to Path (or C-A-c)
* Remove the fill and enable a stroke
* Set the stroke style to 0.2 mm

For some reason some dots are still in the way that need to be removed manually. Since we have a workflow from KiCad to SVG to gcode, it may be worth investing in letting KiCad produce better SVGs.

I found out that there is a name to what we are trying to achieve: isolation routing, cutting away pieces of copper to create lines. I also found out that Flatcam can generate gcode from Gerber files. Tomorrow I'm going to install Flatcam, generate Gerber files from my KiCad design and load it into Flatcam to generate gcode.

=Thursday 30 January 2020=

{{Hint|The solution here is to use the proper printer profile which sets the steps/mm in the Start Gcode of Cura. Use [[File:D3duniversal 8.ini]] and use File->Open Profile... in Cura on OSE Linux or on Lulzbot Cura Linux Edition. Follow the degenerate OSE toolchain to avoid any discrepancies.}}

Change the firmware to use 100 steps/mm for the extruder. The diff is:

<pre>
diff --git a/src/Marlin_Universal/Configuration.h b/src/Marlin_Universal/Configuration.h
index 94ad793..fc3fe50 100644
--- a/src/Marlin_Universal/Configuration.h
+++ b/src/Marlin_Universal/Configuration.h
@@ -486,7 +486,7 @@
Override with M92
X, Y, Z, E0 [, E1[, E2[, E3]]]
*/
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 100 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 425 }

/**
Default Max Feed Rate (mm/s)
</pre>

Tried printing and the result is better than before. I am interested in sending manual gcode to the printer. I've asked around using email.

Uploaded three outputs of a KiCad project for an Arduino on a stripboard. Unfortunately this was done on a newer KiCad version than OSE supports, but this at least documents what I've done.
* [[File:Schematic-arduino.pdf]]
* [[File:Layout-stripboard-arduino-front.pdf]]
* [[File:Layout-stripboard-arduino-back.pdf]]

Redoing the KiCad for a real PCB and not a stripboard in OSE's KiCad. KiCad exports a horrible SVG with 0 length lines with end caps. It looks ok in InkScape, but when creating gcode from it, it isn't visible.

I also gave a brief tutorial on what I know of KiCad (which isn't much, but just enough to create a PCB design).

Holger is able to create a different SVG.

=Wednesday 29 January 2020=

Updating the log. Benedikt has his first print. We found out that the STL file from Don's pen holder design is very bad with holes. Michel is trying to clean it up.

The diode between and behind the X and Y motor drivers has to be cut because we provide the RAMPS board with 24V instead of 12V. It then also powers the arduino. We cut the diode to prevent the RAMPS to power the Arduino. We power the arduino manually.

My X axis doesn't move properly anymore. Changing the small driver shield seems to work. Unfortunately, when doing a test print, it is apparent that it doesn't work properly. If it is not the driver, then it could be the board. Changing the board encompasses removing the diode, and inserting jumpers. We also used E0 as the extruder which means that the original firmware should be uploaded again. This resulted in good movement of the axes, but unfortunately the extruder doesn't move. There are two hypotheses:
# The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
# Not only the board was fried, but the Arduino behind was also fried. This can be confirmed by changing the board.

Changing from E0 to E1 didn't work, so we discard hypothesis 1. We changed the Arduino but it started to behave badly. It was in a boot loop making a sound every half second or so. Connecting the board to the computer also gives us this boot loop. Our conclusion is that coincidentally this Arduino is bad. After changing it, it appears to work well. The printer is printing.

Discussion with Marcin where I proposed to use [https://semver.org/ Semantic Versioning]. The benefit of semantic versioning is that you can see that a project is in the incubation stage (version 0.*.*), whether it is a major API breaking modificiation (for example, moving from 1.2.3 to 2.0.0), an added feature (for example from 1.2.5 to 1.3.0) or a bugfix (for example from 3.2.3 to 3.2.4).
In addition it may be possible to use git for keeping versions more in check. Some of the wiki pages are inconsistent over versions. Using a versioning system such as git could help with this and I would propose to create a Makefile or something that generates wiki pages automatically with all the releases. The wiki can then interact as a kind of a bridge between 'regular users' that understand a wiki and 'power users' that try to keep all the versions in check.

Just printed the extruder cooler with a mount for the Z-sensor and the pen holder. It turned out pretty good, but I have a bit higher flow rate than preferred. The current flow rate is 425 steps/mm for the extruder. We are marking the filament at 100 mm above the extruder and are trying to extrude 50 mm. Strangely enough, much more is extruded than preferred. Let's debug this more thoroughly:
I can only use increments of 4 mm, so let's extrude 20 mm. We record the distance the extruder makes then as: 83 mm. If you look in the settings of the amount of steps, the X, Y, and Z have 80 steps/mm, and the extruder 425 steps/mm. However, the diameter of the belt attachment on the motor axis is not that much more than on the extruder axis. Clearly there is some form of multiplication factor.

Holger's printer has perfect extrusion and performing the same measurement on his printer, extruding 20 mm, results in 85 mm actually extruded. I expected this to be a lower value. Asking in an email if someone knows what is going on, I got a reaction from Luke that exlained to me that the value really has to be 100 steps/mm.

=Tuesday 28 January=

We are reducing the voltage on the motor drivers. 0.4V for X, Y, and the extruder. Marcin says 1.0 for the two Z motors, but the Universal has only one Z motor, so we put it to 0.5V. We can measure directly on the pot meter instead of the measuring point that requires us to remove the heat sink.

I accidentally fried something while measuring the voltage of the extruder: smokes and sparks. After experimenting it turned out that the extruder didn't work. Exchanging drivers didn't work. Rewrote the firmware to use E1 instead of E2. The diff in the firmware:

<pre>diff --git a/src/Marlin_Universal/pins_RAMPS.h b/src/Marlin_Universal/pins_RAMPS.h
index da14a6d..31569a2 100644
--- a/src/Marlin_Universal/pins_RAMPS.h
+++ b/src/Marlin_Universal/pins_RAMPS.h
@@ -105,15 +105,15 @@
#define Z_ENABLE_PIN 62
#define Z_CS_PIN 40

-#define E0_STEP_PIN 26
-#define E0_DIR_PIN 28
-#define E0_ENABLE_PIN 24
-#define E0_CS_PIN 42
-
-#define E1_STEP_PIN 36
-#define E1_DIR_PIN 34
-#define E1_ENABLE_PIN 30
-#define E1_CS_PIN 44
+#define E0_STEP_PIN 36
+#define E0_DIR_PIN 38
+#define E0_ENABLE_PIN 30
+#define E0_CS_PIN 44
+
+#define E1_STEP_PIN 26
+#define E1_DIR_PIN 28
+#define E1_ENABLE_PIN 24
+#define E1_CS_PIN 42

//
// Temperature Sensors
</pre>

Basically, we switched the pins for E0 and E1. This turned out to work but we know that my RAMPS board is partially fried.

Holger had flakey motor wire connections probably because of the rewiring of the cables. The motor made a bad noise and didn't move properly. Pressing them in a bit more worked.

FreeCad introduction by Michel. I designed a simple filament holder end-stop.

Moving on to the pen holder. Don posted a design that I've printed. This is a rather large print. First two attempts failed because of the wrong closeness to the print-bed. Third one ran fine but the print was of very low quality. The print head dropped on the print itself messing up the tension of the belt. After retensioning the belt, the X-axis doesn't work properly anymore. After switching ports from X and Y, the Y axis behaves bad while the X-axis behaves properly. We can conclude that the motors are ok. The driver may be messed up or the board itself (that was already partially fried).

Beber had to build the board from scratch, so he needed to cut the diode that sits between the X and the Y motor driver part. Unfortunately, he didn't know that it is required to bridge the three pins underneath each motor to enable microstepping, so he was dealing with very fast motors or no movement at all. After bridging these, the motors work fine.

Benedikt was dealing with a nozzle that did not reach the bed, because blower was lower. In addition, the Z sensor had a problem with the board. Holger and Benedikt rewired the Z ports in the firmware. Pins 18 and 19 were switched in a similar way as above.

=Monday 27 January=

Debugging printer issues:
* After a print the print-head keeps falling.
* The print head moves out of the dimensions of the board.
* The Z-axis probe should ALWAYS be within bounds of the print bed. Otherwise the printhead will just move down.

=Sunday 26 January 2020=

Confusion about the motor wires. The wires from the US are completely parallel, whereas the wires ordered from Europe are crossed in two different configurations. A Reprap drawing showed us a crossed configuration. Experimenting on the right setup led us to conclude that we need the parallel wires. Rewired all the wrong wires but they are more brittle now. We had problems with moving the axes: we could only move forward but not back on the X-axis. This confused us a lot, but this had to do with the right configuration of the end-stops.

Confusion about the axis set up and what "Home" was: In the firmware, home turned out to be (0, 150, 6) instead of (0, 0, 6). This, in combination with the wrong axes configuration was difficult to debug. Confusion about the direction of the motors. Cables can simply be turned.

The Z-sensor didn't work properly. We rewired it to 5V and then it behaved properly. The led is clearly less bright on 5V and Marcin says that it is less reliable but we have a decent experience with 5V.

The configuration of the pins for the end-stops is:
* start X
* end X
* start Y
* end Y
* start Z
* end Z

The right configuration of end-stops for us is:

X-axis: put the end-stop close to the motor. This would be our 0 point. This means that we need to put the cable of this end-stop in the first pins with the green wire on top.
Y-axis: put the end-stop far from the board. This would be our 150 point, so we have to put the cable in the 4th pins position.
Z-axis: This acts as a normal end-stop switch and it will determine our 0 point. This means that we have to put it in the 5th pins position.

We are able to make a view test prints but the motors are running hot.

=Saturday 25 January 2020=

Building the D3D-Universal. Confusion on where to place the axes. Z-axis sensors are a bit different than the spec, they rate 6-36V, whereas the spec should be 5V. We have to connect the brown wire directly to 24V, so soldering them in. Adapt the power configuration since we are on 240V instead of 110V (US).

Transcription Suggestions CEB Microhouse Build in Belize

2020-03-22T19:50:30Z

Pieter: /* Feedback form 14 */

== Introduction ==

After the CEB Microhouse Build in Belize, all participants took some time to write down general feedback. These feedback forms have been transcribed and consolidated in [[Consolidation Suggestions CEB Microhouse Build in Belize]]. This document contains the transcription of the feedback forms.

== Feedback form 1 ==

* Defined plans which can be followed
* consideration of the equipment inventory

Use checklist manifesto for maximizing build
People who are building their 1st house need a full list it equipment and materials and tools

Prepare people of what is expected of them
Provide resources so those w/o required skills can get them

Allow more time with rest periods

tool and equipment inventory

== Feedback form 2 ==

=== CEB Construction Improvements ===

* Site Cleanliness, clear site of trip hazards, loose rocks, branches, stack material in organized piles near enough to job site for easy retrieval but not too close as to be in the way. (We had to move piles of bricks sometimes just to make space). Clear debris away that could hide snakes, spiders, scorpions.
* Have a designated tool location everyone knows where to get tools and return them. Should be at waist height to avoid bending and under a shaded area we waisted a lot of time tucking down tools, also show people/everyone how to use them! People came here to learn, tool belts would be nice.
* same thing for safety equipment, helmets, ear plugs, glasses, masks, gloves, sunscreen, bug repellent and require their use.

Before every job task have a demonstration to show everyone, not just a few people how to do it. You're not learning how to build a house if you are only familiar with a few of the tasks.

==== Brick laying ====

String lines and plumb bobs are really required to get straight lines, square corners and level brings. If enough time is spent explaining to people their importance and how to work around them it will result in a much beter product. Have the teams of workers layout their job process and walking paths to avoid the string lines and crossing the path of others.

==== Installing roof rafters and other work at heights ====

Proper scaffolding with safety guards is key. Workers on ground must wear helmets and must be taught to be aware and avoid crossing under elevated work areas.

==== General Build ====

There should be designated supervisors, preferably who have previous experience with building and CEBs, to lead the build and keep quality up. This will increase productivity, learning and quality. Eliminating the bottlenecks of everyone trying to find one person to ask questions of, supervisors might pay for room and board only to encourage their participation.

There should be at least 2 sets of job drawings on site at all times for review.

The daily schedule advertised online '''must''' be followed no matter what people came based on this schedule and require more time for learning, conversation, and recovery, not following the schedule is false advertising.

== Feedback form 3 ==

=== Planning ===

Upfront, everybody should have studied the plans. Or at least, there should be good access to the plans. The plans could be extended with a "reasoning" section that explains why certain decisions were made. The plans should highlight critical decisions, such as how the J-hooks are placed, possibly again with reasoning: It is not an Ikea build where we trust the plan to be perfect. The plans we have, need to be adjusted often. Having a section witg the reasoning helps. For example 8 trusses for holding the metal sheets without purlins or going with purlins, we can go with less: 5 trusses. The rigid 5-day timeline does not really prove a point and it should either be longer or we should aim for less.

=== Build site ===

The build site should be cleaner and safer. There were four safety incidents and especially with a community build, this should be prevented as much as possible.

=== Laying bricks ===

The wall is imprecise so we could just as well use a better pattern. A line with instruction is probably a better idea than the boards behind. Otherwise, a laser perhaps?

=== Leadership ===

Much time was lost in discussion. This could have been prevented with everybody knowing the plan and the reasoning. I propose to assign teams (small) working on something and make one the leader in a round-robin fashion. The leader has a final say in the decision and for each new task, a new leader is appointed.

== Feedback form 4 ==

Project

=== #carpentry ===
* work flow

=== #social ===

=== #timeline ===
* during post

#safety

=== A work book ===
A living collaborative work book
As a signifier to respective project or aspect of
and time allocation to collaborate while we are there

1) documentation centralized to a tangible workable degree printed off as [yogi's choice] ad-hoc event leaders version and time allocation throughout the day to work with groups to understand + learn the perspective and "methods behind the madness" of the + their respect over positions + contexts congnively, culturally psychologically

beings also have come together to make their best book
and how the

This is important to me because his is wat I believe to be functional transparency.

Living collaborative
work book
as a signifier + also Aspect

== Feedback form 4 ==

=== Learnings ===

# Place bolts for top plate attachment closer to center of bond beam so trusses don't need to be trimmed
# Takes screws into stucco to make it closer to wall
# No 1-finger rule - set mesh closer to wall
# Note on truss, drawing of truss
# Scree entire wall to get it even (Not done)
# Put door in first
# Cut each end of the floor boards prior to putting them in loft
# The thing that worked the best was the Sade board
# The thing that the wort was lifting the backboard up
# worked great: pressure sprayer
# Make sure we get J-bolts in so ends are caught on both ends
# Make hawk for stucco - easy and fast to spread if you have 1 person feeding 2 stuccoers
# Super dry concrete worked great
# Chaining for laying block by carrying from to wall was effective. But this should have been solved with proper pallet placement
# Learning: Using 1" thick lumber instead of 2x would have worked.
# Impact drivers work to get screws into wood.
# Concrete nails, 1.5", work great for firm plates
# Stucco and concrete proportions are generally great at 1:5, with 1:3 for stucco, 1:55 for concrete.
# Every step needs QC - proper or improper method must be decided up front
# 4 days instead of 5 days is advisable. People peter out after 3 days
# Getting instructions over without good content is impractical. Cutoff for printouts must happen before workshop if printer is not available.
# Teach people how to install hurricane ties: wrong [picture], right [picture]
# Volunteers aren't incentivized properly and that is design for failure.
# Magic happens with relationships
# Watch out for bullshitters who like to talk too much

== Feedback form 5 ==

* Participants could take more ownership of project by studying/reviewing plans online in advance
* Ensure minimal tools and materials are available because important building phases couldn't have been completed had it not for some folks bringing tools
* Even though this is a collaborative and sharing concept, perhaps we should embrace some project management tools to organize established workflow.
* Chicken wire stabilization is very challenging to insert in corners and be able to stucco over without cutting them.
* Wire inserts between block would be better if inserted every other row and no more than 1 foot apart.
* Some brick laying efforts forgot/skipped properly inserting wire inserts.
* Collaborative/individual decision-making on site may undermine important seismic and structural aspects by having participant with little technical background modifying and cutting plans on the spot. Should there be a flow to consult more with others?

=== Stucco / Earthquake Basket Method ===

* We tried to keep the chicken wire about 1cm ("a finger's width") away from the CEBs but it proved very difficult to keep the wire plane flat -- instead, it would bubble and wave, varying between 0cm and 10cm from the CEB wall
** We recommend stapling the mesh to the CEB wall, using about 0.5" (1 cm) to 0.75" (1.5cm) staples.
** Because of the inconsistency, stapling directly to the wall meant that the chicken wire varied from 0cm to 1.5 cm from the wall, but, on average, about 1 cm. This is ideal for the first layer of stucco.
** Once stapled it was easy to add stucco with a hawk and trowel.
* Adding moisture to the dry CEB wall before adding stucco was important for bonding stucco to wall. We poured or splashed water from buckets on to the wall before stuccoing since the CEBs had dried in the sun.

== Feedback form 6 ==

#prep

* Personnel Screener
* Human resources

for congeniality, skills, bullshit quotient, + PATIENCE

printer, paper
whiteboard +/or flipcharts
"masters"
tradesmen
hobbyists
newbies

documentarian-tech
historian/videographer

locals contributing

tool + supply librarian

== Feedback form 7 ==

=== General ===

share existing plans, experiences in advance with others
(share also the mistakes that did happen)

=== Bricklaying ===

the pattern with real overlaps [picture] no [picture] yes
I'm not sure chicken wire will be still intact in few years, I'll opt for fiber textiles instead.

=== Organisation ===

I'd expect bit sturdier leadership which could enable better effectivity of time and skills.

=== Appreciation ===

I really enjoyed talks in the night about research a CEBs with prctical demo of stress test.

== Feedback form 8 ==

=== What have we learned ===
* We need written plans on job site for clarification and for dcoumenting changes we made
* We need a captain/leader -- A foreman to guide the build and assign tasks.
* We need to give the "experience" more weight over the "build" -- accommodation, team building and social time play an important role in the moral of the participants. This ideas that are discussed after workday are huge and meaningful.

== Feedback form 9 ==

=== Prep ===

* architectural plans
* either dimensional lumber or high quality tables saw, planer + tools
* identify people with expertise in advance of the build and make them each "team leads" over the different aspects of the build.
* Have each participant pick their top 5 aspects of the build + then determine which teams they will be assigned.
* Share plans with every "team lead" and each participant
* Divide up the job into categories like "Brick laying crew", "building trusses", etc.
* Tap '''local''' talent, building skills in advance + make sure each participant understands to styles of ways of doing things

== Feedback form 10 ==

=== Planning ===

* Have prework for participants to do (video, e-books, etc.) Printed out, architectural plans, complete with elevation details.

=== Brick laying ===

* Interlocking corners
* String lines and plumb lines (+/- 3" of variation isn't acceptable for a viable product).

=== Material choice ===

* Design for local material (framing was overkill and unwieldy)
* Have designated crew leads/project managers beforehand

== Feedback form 11 ==

1. More fun and social experience to enhance the experience from hard work to a fun learning experience. Maybe evening entertainment with libations and music dancing, merriment

2. Task Delegation:

Delegate each task so participants have a clear idea of what they are doing and expected from each.

- Everyone has a natural propensity to do on thing or another -- It's a matter of knapping these strengths. Maybe a series of questions with multiple choice to pick from of to hone into which is the propensity skill.

== Feedback form 12 ==

=== What to do next time ===

# Spec's and drawings
# Schedule and time lines
# Theory and lab the pro finish
# social
# task delegation

1. Specifications and drawings: A clear design that each participant understands before starting. Blueprint with measurements and dimensions. Specifications on how to perform task at hand.

2. Schedules and time lines: A clear awareness of how long each scope/task take. The breakdown of the task in theory with appropriate tools and hardware on hand and adequate supply.

3. Theory and lab, then pro finish: Many participants are unskilled builders. It's my recommendation there could be more time dedicated to understanding the task in theory/class. Then each task in practice application show to students by skilled craftsperson for 3 hr, 3hr class, 3 hr. practice lab Then class is over and professional builder finish. It's hard to expect so much work from paying volunteers.

4. Social element: Starting at 6am pick-up to 9pm, a total of 13 hr day intensive is hard for the student to grasp all that is taught and experienced in a day. I sense there could be no more than 6 hrs including travel to hotel.

== Feedback form 13 ==

=== Feedback ===
==== Stations ====

In general, pre-arrival, it would be ideal if there could be pre-designated areas or "stations" for the various tasks.

==== Pre-build + actual build differentiation ====

Ideally, I would like to see options for build "shifts" for example, first shift might be 5 days long whch includes creating bricks, prep work, laying foundation etc. Second shift might be 5 days long which includes slurry and brick laying etc. This way, there would be fresh teams for each phase, less rushing, more focus, a weekend between (during which time people could recharge) and people could choose what portion of the learning most applies to them, or remain on site through the duration, participating in the entire build.

==== Create visuals or increase time frame ====

Ultimately, I think 5 days is far too short a time to do a quality swarm build of this style. *Unless* there is more organization before hand, and clarity in terms of distillated, essential information, including a diagram of the build blueprints so there is a visual beforehand.

==== First Aid ====

A First-aid station/location (easily identified) is a '''must''' fro such an uncoordinated untrained team. As is safety gear.

== Feedback form 14 ==

=== Morning learning vs. evening learning ===

After-dinner training *may* be a bad idea, everyone is exhausted, over-saturated, and less able to retain learning. I'd suggest teaching and training involve white boards, chalk boards, hand outs, print outs or slide shows in the morning after breakfast or pre-breakfast so learning is at a prime level. Ideally, evenings would be spent socializing, team bonding, etc.

=== More hands on demonstration ===

I think there was often too much talking, and not enough demonstration /diagrams - for non-verbal learners, this presents an information gap. The demo that Aydan did on day 4 was ideal for day 1 to set the context for the strength of the build.

Also, the brick laying style was not as strong as the locally suggested style. I would prefer the interlocking bricks for structural integrity. [ picture].