Pieter log

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

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:

1. The firmware wasn't correctly uploaded, so it still has the old firmware. This can be confirmed by trying E1 for the extruder.
2. 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).