Pieter log
Hint: see
ose-workbench-platform and 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.
Hint: From: G Roques: OSE has a Slack Channel if you'd like help on certain aspects of Python scripting with FreeCAD such as creating tools, or want to discuss things like documentation generation for parts 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 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 Pandoc from Orgmode. Orgmode is a file format supported by a 'mode' for Emacs, a widely used editor. It allows you to write TODO's, notes, presentations, academic papers in just normal text, similar to 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 Gollum. I would give the members of the meeting Nextcloud accounts and Moritz would set up a Gollum instance.
Sunday 7 June 2020
Install 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 Nextcloud.
Wednesday 27 May 2020
Meeting with Benedikt, Holger and Jos Poortvliet from 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 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 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:
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:
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:
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:
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:
- Primitive Technology, a very fundamental approach to understanding technology
- 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:
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
- Movies
- 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
- 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:
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:
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)
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 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:
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
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).
