The instructions for flashing a BeagleBone Black has long been in dire need of an update, and that day has finally come! The etcher.io (Etcher by RESIN.IO) is a beautifully designed app that runs on Linux, Windows and OS X alike and it does one thing: Burn images to SD cards.

Since Kamikaze is based on the regular BeagleBone Debian distro, the instructions here should work equally well for anyone wanting to flesh the software on their BegleBones. However, keep in mind that newer versions of BeagleBone Debian distros do not have the flasher script enabled by default and will therefore only run from the microSD card on first boot.

The Thing-printer wiki has already been updated with the new burning instructions, but for reference, here are the copy-paste instructions from the video so the one other person using Linux can save an extra click. Windows and OS X users can simply install in the normal manner!

cd ~/Downloads
chmod +x Etcher-linux-x64.AppImage
sudo ./Etcher-linux-x64.AppImage

The video also shows a quick run through on what to expect when flashing the BeagleBone. It’s important to note that the video is cut, and so there will be a significant delay from the first LED light-up until the cylon/night rider patterns starts.

Hopefully a new video will come out soon showing the second part of getting started with a run down of how to connect the BeagleBone to your network and showing the first move. There was recently a poll on the Thing printer G+ page, and so documentation is still a priority for many.

The post Flashing a BeagleBone Black with etcher.io appeared first on www.iagent.no.

Increased reliability with a filament sensor

One of the most annoying things that can happen when printing with 3D-printers is running out of filament or a filament jam. Both are almost unavoidable. There is no infinite filament (yet) and even the best filament manufacturers some times end up with foreign objects in their plastic batches. The thing that will separate current and future 3D-printers is most likely more sensors for monitoring stuff. Take a leap into the future right away by adding a rotary encoder based filament monitor to your Replicape controlled 3D-printer!

Replicape has support for incremental rotary encoders that can be used to monitor the movement of filament past the encoder. Typically a rotary encoder will give off discrete signals as a result of angular movement in one direction. The signals can be used to sense the direction and amount of angular movement the rotary encoder has done, which in turn can be converted into amount of filament consumed by knowing the diameter of the rotary encoders shaft. This information will need to be given to Redeem, in the section Rotary-encoders.

Software side
Behind the scenes, Redeem uses Linux’s rotary encoder kernel driver, which simplifies the development and maintainability of this feature. In order to enable this, you will need to know the number of cycles pr. revolution your encoder emits (cpr-e), the diameter of the wheel brushing against the filament and (diameter-e), and the device on which the events are reported, typically /dev/event/input1 (event-e). The big problem with the current setup is that you you need to reconfigure the devicetree in order to activate the rotary encoder kernel module. There is a document for the Linux kernel describing this binding: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/rotary-encoder.txt.

           rotary@0 {
                compatible = "rotary-encoder";
                gpios = <&gpio3 17 0>, <&gpio0 4 0>;
                linux,axis = ; /* REL_X */
                rotary-encoder,relative-axis;
            };

Since the input device needs to be mentioned in the config file, it might be a good idea to also set up a udev rule symlinking the rotary encoder to a known name. That way, it will always get the same device name. Here is an example:

nano  /etc/udev/rules.d/99-rotary.rules

Place this into that file:

SUBSYSTEM=="input", ACTION=="add", ATTRS{name}=="ocp:rotary@2", SYMLINK+="rotary0"

A working rotary encoder setup for extruder E will look like this:

[Rotary-encoders]
enable-e = True
event-e = /dev/rotary0
cpr-e = -360
diameter-e = 0.003

Place this into:

/etc/redeem/local.cfg

Notice that the event device name (event-e) corresponds to what was set up with the udev rule.

It is also possible to set up an alarm that will trigger if the sensor deviates too much from what it should be.
If you want an alarm for that, set that up like the following:

[Filament-sensors]
# If the error is > 10 cm, sound the alarm
alarm-level-e = 0.1

Currently, if an alarm is triggered, it will send a “pause” action command to OctoPrint.

To visualize the filament use, Toggle now has a built in filament graph. To show it, simply tap the temperature graph to toggle between temperature and filament. To enable the streaming of data from Redeem, use the G-code (or M-code) M409. The token E enables all filament sensors connected, while D disables all. You can also specify which sensor to stream for by using an index after the “E”, so M409 E0 enables streaming for extruder 0 (E).

Electronics part
On the hardware side, two end-stop inputs are needed since a rotary encoder has two outputs. In addition to this they typically need a 5V-ish power source (+5V and GND). All of this can be taken from two end stops on Replicape. In the video posted, I’m using a rotary encoder left by a master student. A quick google search reveals that it is a s4-360-125-b-d, a $100 super smooth optical encoder. While doing research, I also ordered a few cheap rotary encoders from Digi-key, but soon realized that “retention” is not something you want, since it causes “drag” on the encoder. Useful if you want to use it for a user interface, but not so great if you want no additional force for your extruder. These from Digi-key work, but are not recommended for this particular purpose:
http://www.digikey.no/product-detail/en/C14D32P-A3/102-1923-ND/2039183
http://www.digikey.no/product-search/en?keywords=102-1763-nd

Mechanical part
So using the US digital rotary encoder, I created a simple “slide along” filament sensor. It relies on the filament being pushed towards the rotary encoder shaft causing it to rotate. This solution is not ideal, and will easily cause wrongful measurements, from what i have experienced, but it does suffice for a simple experiment.

The post Filament sensor on 3D printer with Replicape appeared first on www.iagent.no.

Redeem, the Replicape Daemon, is the “firmware” that accepts g-codes and makes the 3D-printer move. What is special about this firmware is that it is mostly written in a high level language. Python is not the fastest language around, but offers a large array of libraries optimized in C, garbage collection, favours readability and has very good integration with C/C++. That way most of the code base can be kept in Python, with only a small core optimized in C.

The native path planner, was originally ported from Repetier firmware. The porting was done by Mathieu Monney, and although it has worked great, there have been certain short comings with the code base. Looking through any firmware for 3D-printers, you will see a well of pre-processor directives to optimize the code at compile time based on what type of machine the code will be running on. That is necessary when you have 16 MHz of processing power, 256 KB of total flash storage and 8 KB of SRAM. However, using a modern day platform with 1000 MHz of processing power, 4 GB of flash storage and 512 MB of DDR3 SRAM, the need for compile time optimizations diminishes severely. Add to that a floating point unit, and you no longer have to weigh every use of floats in the code.

An effort has therefore been to move the native path planner into something more suited for BeagleBone Black and similar speced platforms. A side effect to this has been to make the whole path planner more stepper agnostic, meaning that the path planner no longer has any concept of what each axis does what, and will simply merge each axis using the Bresenham algorithm. This enables doing some pretty fancy things, such as having one or more steppers operate in “slave mode“, easily adding more stepper motors, in order to facilitate color mixing etc. It could also be used to specify what each axis does in run time, if one was so inclined.

I’ve recently done some development on this, and although it’s still a fairly early proof of concept, printing objects do work and slave mode seems to behave as it should. I made a quick video showing a demo, along with an explanation.

The post Redeem new features preview appeared first on www.iagent.no.

The wait is over, folks! Replicape revision B is now live on Kickstarter! If you are reading this on Thing-printer.com, you probably know about Replicape, and are mostly interested in what’s new with Rev B compared to Rev A! Here is an overview.

In more human readable form, the most important update is the new stepper drivers. TMC2100 are slightly less powerful than the old DRV8825s, but offer a few advantages. There are now 8 different configurations for the decay modes, as well as the option of interpolation of micro stepping up to 256. In combination with a four layer PCB and a better stepper driver layout, this makes the driver more suitable all around.

Thomas Sanladerer did a test of the SilentStick that has the same drivers on them. His conclusions were very helpful in choosing the new drivers. Here is his review for reference:

The post Replicape rev B Kickstarter is live! appeared first on www.iagent.no.

If the testers give the board their go, that is to say they have not found any major flaws, the Kickstarter campaign is launched. Two of the beta testers are located in California, so Bent and I will jump in a car and do a road trip and visit them to do an in-depth interview about what they think of the new Replicape.

I’ve had a lot of fun making the Kickstarter video for this board, just building (3D-printing) epic camera jigs and testing the new functionalities of the board, both the inductive sensor input and the servo controllers seem to be working as they should.

[evp_embed_video url=”https://scontent.cdninstagram.com/hphotos-xaf1/t50.2886-16/11773411_1625067334424660_928462397_n.mp4″ loop=”true” autoplay=”true”]

Logistics FTW

One thing I should mention about this KS. Since the PCB production is curated by Elmatica, there is no need to wait for the campaign to finish before production starts. They will secure the middle financing. Therefore, as soon as we hit 100 sold units, that is enough to start production! Hopefully that happens within the first few days of the campaign, and so delivery can happen way sooner than 30 days + production.

Another thing worth mentioning is the options for shipping. Elmatica are orders of magnitude better at logistics than a small start-up company, so they will help with securing the shipping agreements, securing swift and super cheap shipping!

The post Beta testers, start your engines! A new Replicape is coming! appeared first on www.iagent.no.

What it does
Without cape manager, you basically have one single device tree blog that is loaded when the kernel starts. If you want to change which peripherals are enabled, you need to recompile the device and reboot. With cape manager, you can choose to change parts of the device tree in a running kernel. This enables loading cape-specific overlays based on the cape that is attached (read from the EEPROM of the cape) or via command line to enable a specific peripheral or mux the pins to a specific function. This is what the Adafruit BBIO library does behind the scenes.

Get started with cape manager
Start with a fresh Debian distro. The official Debain image form March should do.
Install the newest kernel:

apt-cache search linux-image

Pick one of the latest, for instance “linux-image-4.1.1-bone10”:

apt-get install linux-image-4.1.1-bone10

Clone the bb.org device tree overlay repository:

cd /usr/src
git clone https://github.com/RobertCNelson/bb.org-overlays
cd bb.org-overlays

Follow the instructions on how to use upgrade and use the cape manager from there. The instructions are good, basically:
– Upgrade the DTC
– compile the overlays.

Tools for checking your work
The cape manager is now located in a more static location in the sys fs than before. The new location is:

cat /sys/devices/platform/bone_capemgr/slots

To see which capes are loaded, cat it.
If you are working on pin-muxing there are a couple of files that can be useful to cat:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins

This file will give you the pin number, the adress of the pin in physical memory and to which function it has been muxed (1 to 7). It will also tell you if it is set up as input/output in the case of GPIO (function 7) and if it has pull-up or pull-down.
Another useful sysfs file is this:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

This can be used to check that a pin has been claimed in the overlay. Very useful for making sure that the groups you add to the am33xx_pinmux node are actually set up as you want them to be.

Helpful #define files
A while back I posted a table with the mapping from the headers exposing the different pins on the BeagleBone to the physical address of the pins. For a while now there has been a header file defining this mapping and providing user friendly names that can be used for pin muxing. By adding the following includes to the header of your device tree overlay source files, you can use the pin names from the exposed headers verbatim:

#include <dt-bindings/board/am335x-bbw-bbb-base.h>
#include <dt-bindings/pinctrl/am33xx.h>

Instead of writing

    dallas_w1_pins: pinmux_dallas_w1_pins {
        pinctrl-single,pins = < 0x150 0x37 // Dallas 1W >;
    };

You can now write

    dallas_w1_pins: pinmux_dallas_w1_pins {
        pinctrl-single,pins = < BONE_P9_22 (INPUT_EN | PIN_PULLUP | MUX_MODE7) >;
    };

so this saves you from having to look up the pins in a table.

caveats in porting old overlays
A while back I ported the patches for the cape manager to a kernel 3.12 for use in an Angstrom based distro. If you want to port an old cape from the kernel 3.8 era, you will notice that there are a couple of changes. Most importantly that the GPIO banks used to go from 1 to 4, but now go from 0 to 3. Also, the UARTs/serials go from 0 to 6 to match /dev/ttyO* in the file system. You can see this by peeking into the am33xx.dtsi (device tree source inclue file) in the mainline kernel repository: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/am33xx.dtsi#L168

The post Cape manager is back baby! appeared first on www.iagent.no.

One of the key elements of electronics design beyond the elementary workings of the circuits is the thermal management and the EMC (Electro Magnetic Compatibility). On a 3D-printer controller board, the MOSFETs tend to be one of the major contributors to both the EMC part as well as the thermal management part.

For Replicape Rev B, I’ve opted to cut out the gate drivers on the MOSFETs in favour of having the gates driven directly form the PWM driver (PCA9685). The main reason for this was to cut down cost in order to reach the target price of $99 MSRP, but this was only after careful consideration and calculation of the expected heat dissipation from the MOSFETs driving the extruder heaters and heated build plate. I do not recommend doing this if you are going to drive the MOSFETs directly from a BeagleBone Black. It has a mere 6 mA source current and 4 mA sink current on the output pins as well as only 3.3 V output causing the MOSFETs to spend more time in transitions and (most likely) have a higher Rdson value due to the lower gate voltage.

The first prototype board is now back, thank you Elmatica for the quick service and supberb PCBs! I can compare the calculations to actual measurements to better calculate the heat dissipation from each of the MOSFETs. The strange thing is that the rise time across the load did not change for the worse as expected, instead it improved! Considerably!

Here is a picture of the layout of the PCB. The MOSFETs are those three in line with the fuse. The fuse is the yellow thing.

Here are some of the important parameters:
PWM frequency: 1 KHz

Replicape Rev A4A:
Gate voltage: [latex]12 V[/latex]
Rise time measured across load: [latex]50 ns[/latex]
Fall time measured across load: [latex]200 ns[/latex]
[latex]R_{DS(ON)}[/latex] at [latex]12V(GS)[/latex] is [latex]3 m \Omega[/latex]

Replicape Rev B1:
Gate voltage: [latex]5 V[/latex]
Fall time measured across load: [latex]50 ns[/latex]
Rise time measured across load: [latex]50 ns[/latex]
[latex]R_{DS(ON)}[/latex] at [latex]5 V(GS)[/latex] is [latex]4 m \Omega[/latex]

Why has it improved?

Looking at the schematic for the Rev A4A and the Rev B1 board, the difference is the lack of a gate driver in the latter. The gate drivers from the Rev A4 board has a drive capacity of 500 mA both source and sink. This is great if the load that is being switched is in close proximity to the MOSFET, but on a 3D-printer, the load is usually located about a meter away from the board, causing the heater cable to act as an antenna. Therefore, a series resistor of [latex]100 \Omega[/latex] was introduced in series on the gate pin order to limit the rise and fall times and thus limit the bandwidth of the “antenna”. Apparently, the guy doing the calculations on the series resistor was a little eager so the resulting slope became too flat. By removing the gate driver and the series resistor, the slope is instead limited by the maximum source and sink currents of the PWM driver, 10 mA and 25 mA respectively.

The rest of this post will show the calculations on where power is dissipated in the MOSFET and compare the two designs.

Power dissipation during on-time.
To get a base-line on what the worst case heat dissipation is, calculations are done for a MOSFET being fully-on (in saturation) 100% of the period. Looking at the data sheet for AON6758 (figure 3), the [latex]R_{DS(ON)} = 4 m\Omega[/latex] for[latex] V_{GS} = 4.5 V[/latex]. All measurements have been done with a 40W @ 12 V heater element giving a current of
[latex]I_D = \frac{P}{U} = \frac{40 W}{12 V} = 3.33 A [/latex]
and having a resistance of
[latex]R_{HEATER} = \frac{U}{I_D} = \frac{12 V}{3.33 A} = 3.6 \Omega[/latex]
Knowing the current through the heater and the on-resistance of the MOSFET, we can calculate the power dissipated in the MOSFET:
[latex]P_{MOSFET} = U_{DS} I_{D} = R_{DS(ON)}xI_{D}^2 = 0.004 \Omega x 3.33^2 A = 0.044 W[/latex]

On Replicape Rev A4A, the gate driver gave a [latex]V_{GS}[/latex] of 12 V which in turn gave an [latex]R_{DS(ON)} = 3 m\Omega[/latex], giving a heat dissipation of 0.033 W.

Power dissipation during off-time
For completeness, I’m including the power dissipation during off-time as well. Intuitively it is negligible, but let’s grab the boob and do the math to be sure.
Looking at the data sheet, the leakage current when the MOSFET is fully off is
[latex]I_{DSS} = 0.5 mA[/latex] for [latex]V_{GS} = 0 V[/latex]
In this case all the voltage lies across the drain-source, so we have
[latex]P_{DSS} = U_{DS} \times I_{DSS} = 12V \times 0.5 mA = 0.006 W[/latex]
This is an order of magnitude lower than on-time, but this increases as a function of temperature up to a reported 100 mA for a junction temperature of 125 degrees.

Power dissipation during transitions.
So what about during the transitions? To calculate that, it’s necessary to look at the power as a function of time. The average power is the integral of the pulse divided by the period. Look:
[latex] P_\mathrm{avg} = \frac{1}{T} \int_{0}^{T}p(t) \mathrm{d}t [/latex]
Looking at the rise and fall transitions, we can approximate the curve by a second order polynomial curve. With a little trial and error,
I landed on the following values:
[latex] V(t) = 4.4 \times 10^{8} t + 4.0 \times 10^{15} t^2 [/latex]
From this, the drain current was calculated and also the voltage across the drain and source of the MOSFET giving the necessary
parameters for modelling the power dissipated in the MOSFET during the transitions. Here is a plot of the [latex]V_{DS}[/latex], the drain current and the resulting power dissipated. Note that even though the peak power reaches 10 W, this is only for a short time. The picture below shows the plot of the voltage across the MOSFET, the current going through it and the resulting power being dissipated during a rise transition.

Some quick calculations reveal that
[latex]P_{AVG} = \frac{1}{T}\int_0^T At – Bt^2 dt = \frac{1}{T}(\frac{1}{2}At^2 – \frac{1}{3}Bt^3) |_0^T[/latex]
[latex]= \frac{1}{T}(\frac{1}{2}AT^2 – \frac{1}{3}BT^3) = \frac{1}{2}AT – \frac{1}{3}BT^2[/latex]
Using the values from before, reveals an effect loss of 7.66 W during the rise transition. a Similar value can be expected during the fall transition.

Steady state heat dissipation
For a 50% duty cycle at 1 KHz the average dissipation will then be 0.78 W. Now please note that this is a fairly crude first order
approach to the heat dissipation calculations. Still, with the right layout with at least 1 in^2 copper, the packages should be able to dissipate between 2.6 and 4.1 W according to the data sheet which is far below what these calculations show. Comparing this to some of the other boards that has had this calculation done for them, it looks pretty good!

The post Power dissipation calculations in MOSFETs appeared first on www.iagent.no.

Kamikaze is a Debian-based eMMC flasher image for BeagleBone Black. It is a complete solution for Replicape and Manga-Screen aiming to contain all software needed to slice a model and print it without installing any additional software. And it has now been updated!

The latest image has an updated Octoprint 1.2 which now has CuraEngine as a plugin simplifying the slicing of models. So now, you can upload Cura slicer profiles directly from Octoprint.  Further, I’ve made a plugin for Redeem, meaning that you can also import Redeem config files and restart redeem from the Octoprint settings window.

The new image also has the ADC bug removed that was present in the last release. There is also support for Replicape Rev B1, of which there only exists one prototype 🙂 This image also has Linux kernel 4.1.0-bone9 with cape manager, so the right device tree is loaded based on the EEPROM on your cape.

There are still a few things I want to fix in an upcoming version, namely having the zeroconf plugin for Octoprint work out of the box, so there will probably be another distro coming in a while. Also, a big project will be better integration between Octoprint and Toggle so it is possible to see which model is printing and progress on both screens.

The post New Kamikaze CNC image released appeared first on www.iagent.no.

Short summary of parameters
– PWM frequency: 10 KHz (PCA9685 is limited to 1 KHz, see below)
– First order low pass filter with R = 10K, C = 47uF
– Corner frequency: fc = 3.38Hz
– Peak to peak ripple voltage: 0.53 mV
– DAC resolution step: 0.61 mV
– DAC max voltage: 2.5V

Why is it necessary?
The DAC chip used in Replicape rev A4A was $1.75 in volumes of 500. Removing this cost does seem like a big deal, but when the total BOM cost is $30-40, it makes up a large percentage of the manufacturing costs. But what are the downsides to eliminating this component? Will it give a worse result in any way? Probably not.

What is the challenge here?
Well, in summary; to get a programmable bias voltage between 0 and 2.5 V with enough steps (4096 is plenty) and with a low enough ripple voltage (5.3mV should suffice) at a low cost (the price of 5 resistors and 5 capacitors).

Why don’t you use trim pots?
Trim pot’s are cheap, that’s it. The downside is that the end user will need physical access to the controller board to change it and for 3D-printer manufacturers, they will need to calibrate the current during assembly. This increases cost during assembly for the manufacturer and makes it less use friendly for the end user. An important aspect about Replicape is that physical access should not be necessary once the board is installed.

The electro-pop
The PWM chip has a VCC of 5V while the AIN voltage is needs 0-2.5 V. For this reason, a voltage divider is added followed by a first order low pass RC filter.The voltage divider is not really necessary since the AIN input can handle up to 5V with anything above 2.5V being treated as full current. It might be eliminated in a new revision (at the expense of only having half the resolution). Here is the schematic for the filter, the input is a PWM pulse, the output is a bias voltage.

Possible attainable DAC resolution
The PCA9685 has a 12 bit resolution. Some quick front of the blog calculations makes the theoretically attainable resolution
[latex]V_{step} = 2.5V/4096 = 0.61 mV[/latex].
This is more than enough. Typically you will change the current limit in steps of 0.1 V, but having a good resolution minimizes the difference between what you want and what you get without pulling out a calculator.
An interesting observation will be to try and measure the noise level on this input pin and see if the noise level on the pin or on the GND plane of the board will be below that.
Conversely, and even if one is not interested in having the option to use every bit of the resolution, having any ripple on the AIN pin will manifest itself in variations in the current cut-off which again will increase the audible level from the steppers.

PWM frequency
The frequency/period of the PWM outputs do not really matter for the operation (see the appendix for why). Or rather, it matters, but not for producing a bias voltage. Instead it is critical due to the amount of ripple voltage that is tolerable. To get a point of reference for what is tolerable, in the datasheet for TMC2100, there is a small section on driving the analogue current control from a filtered PWM circuit. In the data sheet, a PWM frequency of “well above 10 kHz” is recommended together with a first order filter with R = 22k and C = 1uF. This should give a corner frequency of fc = 7 Hz, equivalent with a time constant of 22 ms (“several milliseconds” as specified in the data sheet). With the values suggested, the steady state ripple voltage on the input pin is 2.8 mV. This is still an order of magnitude above what is the PWM resolution limit.

Yeah Bill, but why not simply increase the PWM frequency?
Normally, I would say go for it, but on Replicape, the PWM chip has multiple uses (It is also very limited, see below). It is also used for controlling the heaters on the board. Since MOSFETs dissipates more heat in the transition phases than in the steady states (on/off), simply increasing the PWM frequency will increase the total amount of heat coming from the MOSFETs. How much will be the topic of a different blog post!

Lowering cut-off frequency
An alternative to increasing the PWM frequency is lowering the cut-off/corner frequency. Since the actual cut-off frequency is not critical, it can be a good idea to spend some time finding values on the R and C that can also be used other places on the board to save BOM lines. In the case of Replicape, 10 K and 4.7 uF were used, giving a cut-off frequency of 3.4 Hz and a Vpp ripple of 1.3 mV. This is still above the resolution, but gives very nice (and cheap) R and C values.

Bandwidth considerations
Normally, when using a DAC for any application, you are also interested in the bandwidth that the DAC can provide. However, in this case, we are only interested in setting a comparator voltage, which does not have to change very rapidly. That’s why we can get away with having a low cut-off 1st order filter. The DAC has a bandwith of 3.38 Hz, if you need to change the stepper current more often than 3 times pr. second, then dude, you are doing it wrong 🙂

What are the downsides?
The only real downside I can think of is the increased heat dissipation that will come from the increased switching frequency of the MOSFETs. Also, the previous revision of Replicape used the same PWM chip for also controlling servos. This locked the PWM frequency to 100 Hz (!) which is the period needed for servos. Instead the two servo ports available now are controlled by PWM pins on the SoC. There is always an alternative to add a second order to the filter and then decrease the frequency alternatively tolerate a higher ripple voltage. There might not be much increase in the audible level anyways.

Second order filter

I’ve later found out a couple of things about the PCA9685 PWM chip. First of all, the maximum frequency attainable is around 1 KHz according to the data sheet (but I’ve measured it to 1.76 KHz). Furthermore, the accuracy of the frequency is not very good. I’ve seen differences of 15% between the frequency given and the frequency it outputs . This is not critical for controlling heaters or making bias voltages, but could prove fatal in other applications such as controlling servos etc.

The upper limit of 1 KHz means that there will likely be a need for a second (equal) filter, making the drop-off -40dB/decade. With a second order RC low pass filter, the peak-to-peak voltage drops to below 0.02 mV. I did a quick bread board implementation of this and with my crappy Oscilloscope measured the ripple voltage to 0.8 mV which is likely the noise floor of the oscilloscope with 256 times averaging. The good news is that the voltage divider can be directly substituted for a second RC low pass filter by replacing R1 with 10 K, R2 with a 4.7uF capacitor.

Comparing simulation and a physical implementation

In order to compare the calculated results with a physical implementation, the frequency was lowered to 100 Hz to increase the ripple voltage to something measurable. The V in is 3.3V since this is the Vcc on the PWM circuit on Replicape rev A4A.
The following photo shows a simulation of a PWM (blue) signal, its fourier series implementation (green) and the ripple voltage (red) in the time domain. Also shown is a second order low pass RC filter gain and phase shift. The two RC filters are equal and having the same parameters as previously. The calculated ripple voltage is here 5.0 mV peak to peak. An interesting observation is the 180 degree phase shift

For comparison, here is a picture of the same implementation in hardware. The ripple voltage is here around 10 mV as seen on the oscilloscope.

There is a small difference between the simulated results and the hardware implementation. Looking at the datasheet for the capacitors, one reason might be the bias voltage that lowers the capacitance with about 25% at 3.3V. Implementing this is in the formula gives a Vpp ripple of 9.5 mV which is pretty close to the calculated results.

Appendix: get your math did

Filtering a PWM signal through a low pass filter will give an analogue bias voltage proportional to the duty cycle of the PWM. This is the wanted signal. In addition to this, there will be an “unwanted” component, a ripple voltage appearing on top of the bias voltage. The appendix shows the calculations for why this is true and also the steps for calculating the ripple voltage.

What we are interested in is the average value of the function, and also looking at the ripple voltage resulting from the chosen filter. 12th grade calculus comes to the rescue in the form of integration! PWM is just a train of pulses, so by integrating over time, the value becomes a constant scaled by the pulse of the width. Look:

A straight forward way to define this signal mathematically is with the use of a Heaviside step function:
[latex]f(t) = K(1-H(t-D))[/latex]
where K is a scale factor, (2.5 V in this case after the voltage divier), D is the “on” time and [latex]H(t)[/latex] is the heaviside delta function which can be written as
[latex]H(t)=\begin{cases}1, & \text{if $t<0$}.\\ 0, & \text{otherwise}.\end{cases}[/latex]
This function is defined in the interval
[latex]\left[0, T\right][/latex]
However, looking at the steady state PWM signal, it can be considerered a piecewise continuous function on [0, T]. Using fourier series, the square wave can be decomposed in to a series of complex exponentials. The normal definition of the fourier series is
[latex]f(x) = a_0+\sum_{n=1}^{\infty}a_n cos(nx)+\sum_{n=1}^{\infty}b_n sin(nx)[/latex]
where
[latex]a_0 = \frac{1}{2\pi}\int_{-\pi}^{\pi} f(x) dx[/latex]
[latex]a_n = \frac{1}{\pi}\int_{-\pi}^{\pi} cos(n x)f(x) dx[/latex]
[latex]b_n = \frac{1}{\pi}\int_{-\pi}^{\pi} sin(n x)f(x) dx[/latex]
[latex]x \in [-\pi, \pi][/latex]
Jeezes, this is hairy! But right off the bat, we can eliminate the [latex]a_n[/latex] coefficients, since the function
is odd.

Changing integration limits
The interval on which this is defined is not ideal, instead we change the integration limits
to something a bit more manageable. A PWM signal is usually defined by a period and a duty cycle, so lets change the integration interval from
[latex]\left[-\pi, \pi\right][/latex] to [latex]\left[0, T\right][/latex]. We the have
[latex]x = \frac{2\pi t}{T}[/latex]
[latex]dx = \frac{2\pi dt}{T}[/latex]
We then have
[latex]f(t) = a_0+\sum_{n=1}^{\infty}b_n sin(\frac{2\pi nt}{T})[/latex]
where
[latex]a_0 = \frac{1}{T}\int_{0}^{T}f(t) dt[/latex]
[latex]b_n = \frac{2}{T}\int_{0}^{T}f(t) sin(\frac{2\pi nt}{T}) dt[/latex]

Calculating the bias term
Looking at the bias term, [latex]a_0[/latex] we have two peicewise continous functions which each can be integrated.
[latex]a_0 = \frac{1}{T}(\int_{0}^{D}1 dt + \int_{D}^{T}0 dt)[/latex]
[latex]a_0 = \frac{1}{T}(\int_{0}^{D}1 dt)[/latex]
[latex]a_0 = \frac{1}{T}(D-0)[/latex]
[latex]a_0 = \frac{D}{T}[/latex]
So, the bias term is simply the fraction of on-time in the period, which is what we wanted to show.

Calculating the fourier coefficients
To get the ripple voltage, wee need to know the fourier series coefficients
[latex]b_n = \frac{2}{T}\int_{0}^{T}f(t)sin(\frac{2\pi nt}{T}) dt[/latex]
Splitting this up into two integrals yields
[latex]b_n = \frac{2}{T}\int_{0}^{D}f(t)sin(\frac{2\pi nt}{T}) dt + \int_{D}^{T}f(t)sin(\frac{2n\pi t}{T}) dt[/latex]
The last term disappears since [latex]f(t) = 0[/latex]. The first term reduces to
[latex]b_n = \frac{2}{T}\int_{0}^{D}sin(\frac{2\pi nt}{T}) dt [/latex]
[latex]b_n = \frac{2}{T}\frac{T}{2\pi nt} sin(\frac{2\pi nt}{T})\bigg|_{0}^D [/latex]
[latex]b_n = \frac{1}{\pi n} (-cos(\frac{2\pi nD}{T})+cos(0))[/latex]
[latex]b_n = \frac{1}{\pi n}(1-cos(\frac{2\pi nD}{T})[/latex]

The full fourier series for a the PWM is therefore
[latex]f(t) = \frac{D}{T} +\sum_{n=1}^{\infty}\frac{1}{\pi n}(1-cos(\frac{2\pi nD}{T})) sin(\frac{2\pi nt}{T}) [/latex]

50% duty cycle
For a 50% duty cycle, [latex]D = \frac{T}{2}[/latex], so we have
[latex]a_0 = \frac{D}{2D} = \frac{1}{2}[/latex]
[latex]b_n = \frac{1}{\pi n}(1-cos(\frac{\pi nT}{T})[/latex]
[latex]b_n = \frac{1}{\pi n}(1-cos(\pi n))[/latex]

This evaluates to 0 for even n, so it can be simplified to
[latex]b_n = \frac{2}{\pi n}[/latex]
[latex]n = 1,3,5…[/latex]
So for a 50% duty cycle, we have
[latex]f(t) = \frac{1}{2}+\sum_{n=1}^{\infty}\frac{2}{\pi n} sin(\frac{2\pi nt}{T})[/latex]
for [latex]n = 1,3,5…[/latex]

Calculating the ripple voltage
So the b_n terms form an infinite sum, but after the first term there is a big fucking drop-off and
also, since this is filtered through a low pass filter, we can choose just one or or two of the terms and still get a pretty good
estimate.

The gain of a first order RC filter can be calculated as
[latex]G(\omega) = \frac{1}{\sqrt{1+(\omega R C)^2}}[/latex]
Plotting this in a Bode diagram yields the usual -20dB/decade roll-off that first order filters provide.

To find the ripple voltage for a low pass filter, we need to calculate the sum of the fourier series coefficients

[latex]V_{ripple} = \sum_{n=1}^{\infty}\frac{1}{\sqrt{1+(n \omega_0 R C)^2}} 2 \frac{2}{\pi n}[/latex]
where [latex]\omega_0 = 2 \pi f_0 = \frac{2\pi}{T}[/latex] is the angular frequency of the PWM signal, R is the resistance and C is the capacitance.
Simplifying yields
[latex]V_{ripple} = \sum_{n=1}^{\infty}\frac{4}{\pi n \sqrt{1+(n \omega_0 R C)^2}}[/latex]
Plugging the chosen values for R, C, and f and summing the first three coefficients will give a peak to peak ripple voltage of
[latex]V_{ripple} = \sum_{n=1}^{3}\frac{4}{\pi n \sqrt{1+(n 2\pi 10^4*4.7*10^{-6})^2}} = 5.4 mV[/latex]

Now the above calculations are somewhat crude in that they do not take the phase of the signal into account. Looking at a physical implementation
will show that the ripple voltage is 90 degrees shifted forward and has a triangle shape. Still it gives an indication of what to expect.

The post PWM as DAC appeared first on www.iagent.no.

Don’t believe the hype though, even though they are super silent with the StealthChop, that mode is all but useless for 3D-printing. Still, they offer a few more options for tuning the audible noise level, which I’m really looking forward to playing around with. Other than that, one of the major improvements is the price point. By changing manufacturer (see below), opting for a higher volume, doing some electronics voodoo (eliminating the DAC by leveraging some spare channels on the PWM chip etc.), the MSRP of $99 looks like it can be achieved as hoped. This does not mean that the board will be a worse product, quite the opposite. For this price, I’ve managed to add
– Brand new stepper drivers (TMC2100) for up to 256 times microstepping. (actually they are cheaper than DRV8825s)
– input protection on all end stops enabling up to 15V inputs (so you can use proximity sensors directly on end-stops
– reverse polarity protection on input (in case you get unlucky)
– four layer PCB giving lower EMC noise levels
– lower audible noise levels (ground return noise increased the audible levels)
– an additional fan output
– PWM enable (in conjunction with the Watchdog, increases safety in case of a kernel panic)
– Two 5V servo outputs, so you can add a physical Z-probe or Dual drive extruder (http://www.dglass3d.com/products/hpx2max/).

A second thing I’m excited about is the cooperation with Elmatica on the new revision prototypes. These guys have over 40 years of experience in the PCB business and they have been kind enough to do me a solid and help with the prototypes pro-Bono. They are also hooking me up with some sweet connections for the PCB production over in China, so the new boards will be top quality at a low price. In their words: “We’ll hook you up with someone who will not screw you over!”. Music to my ears. In fact, hearing that, I sort of felt like Jules in Pulp Fiction when Marcellus offers to send The Wolf. (See image below).

The plan now is to do a little prototyping for a few weeks and then kick off a Kickstarter to get the volume up to at least a couple of hundred boards which should enable a batch size of 500. By that time, the new Kamikaze CNC image should be stable with a Redeem V1.0

The post New major revision of Replicape (Rev B) appeared first on www.iagent.no.