Fixing makerbot replicator 2 acrylic build plate.

Having problems getting a good print out of your old makerbot replicator?  If yours is like mine the build plate is so warped that anything you print will stick too hard in places and not stick at all in other places.

This project is on thingiverse. 

A disclaimer, this fix worked for me, have no idea if it will work for anyone else. For all I know it might break your build plate in half or do something equally awful. I had to fix a jam during this process because my warpage was so amazingly great that it wrapped about a foot of filament all around the inside of my extruder. You have been warned!

My acrylic build plate had warped over the years. So I tried standing on it to straiten it out and snapped it in half. With the makerware software I could make a good print using a raft. But when I switched to cura on octopi the raft was stuck hard to the prints. I tried putting packing tape down on top of the raft and that did work.

Then I had a thought. Why not print a raft just once covering the entire build plate, permanently attached to the surface of my broken build plate? Then I could print anything and it would come right off. And it worked!

Just clean your build plate and level it as well as you can. Then print the thin8.stl onto the plate with no raft. If your warpage is really bad you might want to try printing a few smaller shapes in the center or around the outside edge depending on your warpage to get the plate in the ballpark so that this will even work. Try to get it to stick as well as you can because ideally it will be the level surface you print on here on out. The first few layers might not evenly cover, because of build plate warpage. And I had to clear out a filament jam in the extruder motor section because of how much my plate was warped up on each corner.

Once the build of the new surface was complete, I covered the surface with packing tape, overlapping it slightly. I put glue stick down on this, lightly, mixed it with a few drops of water and made sure it covered the area where I am going to print. You also have to move the bed down a bit because this new surface is higher than the old surface, by loosening the thumb screws under the bed, and then just move the head around and use the thumb screws and your eyeball to get the tip of the nozzle just to the surface of the bed. Turning the thumb screws left lowers the bed, turning right raises the bed.

I print with a couple of brims and manually adjust the thumb screws as the brim is being laid down making sure that the filament is flat, not round, but not too flat. The brim should be even clear around the print.

My prints now come out with a shiny surface where it was against the packing tape and they just pull off by hand with just a bit of effort.

When I was able to just pull the print off by hand with just a little tug, I almost cried because of the trauma I have endured over the years stabbing myself with razors and putty knives trying to remove prints.

USB raspberry pi zero computer

I built a pi zero with a male usb end attached. It looks like a giant thumb drive. It is like a parasite, in that it uses the keyboard, mouse, monitor and network connection of the attached host, all through the usb connection. This gives me a full UNIX environment even when I am on window Boxen. 

I initially read about it on thingiverse, but the write up for it is here: https://www.novaspirit.com/2016/10/18/raspberry-pi-zero-usb-dongle/

I put a cover on the other side too, to protect the chips and connectors. 

Using RDP the screen updates very slowly, and the desktop is slow just because the pi zero only has 512MB of RAM.  But the ssh command line using putty is perfect.  

I had to do a few more things on the windows side than is given in the above write up, I found another website that talked about how to get it running on windows here:  
https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget

Basically I loaded bonjour print services from apple, set an ip address into the interface, and bridged the ethernet gadget with the interface that had an internet connection. 

Once ping raspberrypi.local starts working then you can get an ssh connection with putty, log in as pi, and I had to

sudo apt-get install xrpd

then after each time the device boots I have to restart the xrdp service for some reason, and when I kept getting a grey screen I killed another instance of X on the pi zero and could then get the desktop to load in windows remote client. 

I am interested in trying to load something like OWN cloud onto the drive and seeing how good the device will act as a cloud server.

A new way to look at small project building.

When I got the 37 sensor kit a few years ago I figured out what was wrong with how normal arduinos are used to built circuits. Using these little sensors and devices mounted on tiny break out boards with connectors already in place, it was easy to connect them back to a breadboard for power and ground and wire up the data line to an Arduino data pin.  

The normal pinouts on an Arduino are difficult. You can't even mount a normal Arduino board on a breadboard (and visa versa), because one set of the pins are wrong.  Every model is lacking all the 5v and ground connections a normal project needs. The normal board is too big and the small boards have strange pinouts as well.

What we need is a board that will have rows of dozens of connections that accept a clip in connector.  And then have sensors be on tiny boards that accept the other end of that connector. I can see a 5 pin connector being used. ground, +5v, +3v, digital, and analog on the first 7 connections, or however many the built in chip supports . After that just have 4 pin connectors without the analog.   If an Arduino Mega was used for this kit you could have 16 analogs inputs. A Raspberry pi with an 8 or 16 port analog to digital converter could work too.

Have various length cables with the clip in connectors on both ends for building various projects.  This is similar to the tinker kit connectors, but with every option in every connector so you literally cannot hook it up wrong.

Come with a few simple devices already wired to the boards, just like the 37 sensor kit did, but make these connectors ones that clip in and are all wired identically, ready to go.  Have extra blank protoboards in the kit to let people build their own devices and connect the same way that the standard pins connected. Release the eagle files to let people build their own protoboards and designs as well. 

I would have the device and boards sit in a plastic carrier that is compatible with Lego, letting you build your projects on the Lego base plates.  As you get more advanced with your projects you could still wire up all the individual digital and analog pins up to a breadboard (also in Lego compatible bases.) Additional kits could be sold beyond the base kit to explore different technologies.  You could even have spi connectors with boards that let you daisy chain the boards together, but that used the same connectors and pins, but were wired a little differently. 

As for the software, I am picturing an extra program that you just say what you have connected up, and which connector you have it attached to, and then you push a button, it creates an Arduino project with the right libraries installed and names attached to the correct pins, and everything already initialized for you, and starts Arduino software loading that package to let you go from there.  

Think of this project as "Arduino For Everyone." 

Planning on building a new home server.

All my computer hardware is ancient at this point.  The old server that I got second hand blew up on me, so I am looking at getting back up to the trailing edge of technology again.

Start with an 8 core AMD processor with 16GB  of RAM, an over-sized power supply, a small 128GB SSD for the OS, and a 4 or 5 TB hard drive stuck in a tower case. Over time I want to double the RAM and add 5 more hard drives of similar size. If needed I can add a PCI hard drive controller with 4 more connections. Later I could copy the OS to a bigger SSD and put the smaller drive in a laptop whose hard drive just died.

The plan right now is to install Debian Linux and use LVM to mange the drives. This way as I add more drives in the future I can add new partitions and expand/move existing ones. I plan on creating partitions to store data the same size as the external usb drives I am currently using to store my files. This way I can always easily back up the data to the external drives as needed.  I can store the back up drives at other people's houses in case my own location suffers some sort of badness.  And everything should be encrypted on disk.

Use SMB to share files on my local network. Setup a media server on the box to share media files to my portable devices. Connect the OSMC raspberry pi box to the main server to see all its files.  This gets rid of a bunch of usb hard drives that sit behind my TV right now.

Use KVM to create virtual machines so I can run a dozen other operating systems at the same time.  Setting up development environments for different versions of windows and Linux.  Things like eclipse and rails have enough dependencies that conflict with other packages that they really need to be in their own bubbles of existence. I can't tell you how often doing some upgrade or install of one thing hosed another package on my desktop machine.  Not to mention just how bloated things get after a few years of constantly adding package after package to the same desktop.

Xen might be better.

And if I run a service like file sharing, that should be in it's own virtual machine.  In fact, I am actually leaning toward doing almost nothing directly in hardware and installing just a minimal operating system at the hardware level and actually running my own desktop as a virtual machine.  Open stack might be interesting to try out for these services.

And finally I want to use thin clients to access this server and the operating systems running on it.  A raspberry pi, even the $5 one, should have more than enough power to run a desktop as an X-terminal server.  And the $30 one now has wifi built in and bluetooth for a keyboard.  I would love to have a half dozen terminals scattered around my place, able to log into my desktop and access the virtual machines. There are actually some distros that give thin client access to many different systems.

The beauty of thin clients is that you save so much time by not having to configure and manage multiple laptops and desktops. If the terminal server dies, you can just switch to another screen and keep working.   Everything is done directly from the main server, so you only have one system to manage and backup.  And if you have multiple users on that same box and each user runs similar programs, the binaries only have to be loaded once, so that once one person runs a Chromium browser, that is in memory so for the next person their browser starts almost instantly.

Getting Pico/SVOX text to speech converter working under Debian 8

Pico TTS is in non free, and by default you do not have access to these repositories when you first install Debian.  In /etc/apt/sources.list  add 

contrib nonfree 

after main on all the jessie deb lines. 

Now you have to install the TTS library and some audio video tools.  Run the following command: 

sudo apt-get install libttspico0 libttspico-utils libttspico-data libav-tools

Now find the command line utility to allow you to create sound files from text, or just play them to the sound card. it is here:  https://github.com/nano13/nvcli/tree/master/synthDrivers/linux/svox_pico

Download these files, make them executable, and put them in a bin folder in your path. 

After you do that then run the different commands and they will tell you what their options are.  You can also just read the python script to see what the scripts can do for you.

I went another route and found this first: https://github.com/nano13/nvcli/tree/master/synthDrivers/linux/svox_pico/trash

And downloaded those two files, made them executable, and then used the following script to convert text to an mp3 file. 

#!/bin/bash
./pico_read_text_file.py  --rate=80% --pitch=110%  --audible "false" --output "$1.wav" "$1"
rm -rf "$1.mp3"
avconv -i "$1.wav" -b 96k "$1.mp3"
rm -rf "$1.wav"

The Results

The output was far superior to espeak, and is very lifelike. When I was growing up I had a commodore 64 and we had an 8kb voice synthesizer called SAM.  So to see the progress in just a couple of decades is amazing to me. 

Future Projects

This would be awesome if I can get it to run on Raspberry Pi computers.  http://rpihome.blogspot.com/2015/02/installing-pico-tts.html

My blog has broken 50,000 page views. :D

My blog passed 50,000 page views today.  I want to thank everyone who has visited and helped me pass this goal.  

Low Power Scheduling Library for Arduino 328U

I wrote my own scheduling library for Arduino a couple of years ago. One of the to-do's for that project was to replace the main loop with a sleep/power down feature that would reduce power down but still accurately wake up and perform the tasks when required.

The reasons that you want to use less power for a microcontroller project is easy.  You want your project to run longer on a set of batteries.  You want your solar powered project to work with the smaller, cheaper solar panel.  You want your coin cell powered camera trigger to work for years, instead of months.

Last weekend I sat down to actually program the power saving feature that I had imaged a couple of years ago. My first few dozen tries failed, and on Sunday of last weekend all I had working was to put the processor in idle mode.  Which I took as a win, because at least the sleep functions of my program were working.

I read a lot of various web pages about how to use the watch dog timer on Arduino, but the one that actually let me figure it out was the post that starts with "OK, I think I have it" on this web page.  I used that example program as a simple example that worked to figure out what I was doing wrong.  I found that example this weekend, after poking at things all week long and going to sleep thinking about the problem.

The first draft of my code that actually worked was just uploaded to github. There were just 2 tricky changes I had to make to my library code.

The first one was the fact that the watchdog timer can't be set to trigger at any arbitrary length of time.  It only triggers at discrete units of time, sort of like a quantum energy emission.  So I put a loop in that found the largest block of time that could fit in the scheduled time, and went to sleep for that amount of time, then it would wake up when the watch dog timer fired and find the next largest remaining block of time that could fit in the delay we needed.  If there is a little bit of time left that is less than the 15ms minimum time that is left, I just delay.

The second thing was the fact that my code requires the use of the millis() function call, but that the timer in the micro-processor that keeps track of time is suspended when the chip is in power down mode.  So to fix this I just drag all the scheduled tasks ahead by the amount of time that I just slept. A side effect of this is that because this timer almost never runs, I think I fixed the 50 day timer wrap problem. :D

One of the most difficult things to figure out was that for some reason the function to set the watch dog timer delay was not working, you had to set the register directly.  From the example code that helped me figure this out.

void myWatchdogEnable() {    

// turn on watchdog timer;   

// interrupt mode every 2.0s cli();  

MCUSR = 0;  

WDTCSR |= B00011000;  

WDTCSR = B01000111;  

sei();}

The line "WDTCSR = B01000111;" is doing two things.  The B01000000 is closing changes to this register and the B00000111 is setting the time to 2 seconds.    The flag WDTO_2S is 7 which in binary is B00000111.

For my own code I had to set the same register with this line:

WDTCSR = B01000000 | period; 

The period was passed into the sleep function and was chosen from the list of flags in the wdt library header file:

0 = WDTO_15MS
1 = WDTO_30MS
2 = WDTO_60MS
3 = WDTO_120MS
4 = WDTO_250MS
5 = WDTO_500MS
6 = WDTO_1S
7 = WDTO_2S
8 = WDTO_4S
9 = WDTO_8S

The results.

And because Science requires documentation, I used my multi-meter to measure the difference between my old and new scheduling libraries using my clock sketch.

My test rig, the clock is wired up in series with multi-meter measuring milli amps.

After.

Before.

As you can see, the change is nearly a 50% power savings. And this is not even optimizing the hardware being used to reduce wasted current.  How would you like your Arduino project to run for 18 hours instead of 10 hours on one charge?

Improvements.

• Figure out why I could not use the 4 or 8 second delays with the old chip I am using.  Waking up every 2 seconds uses 4 times the power of just waking up once every 8 seconds.  Are these timings only usable on specific or newer chips?  Does this need to be an option that someone can set if the bigger timings don't work for their platform?
• 
  
• Get rid of the pointers for next/prev and instead just use a small array to track the tasks. Limit the number of tasks to less than 256 and we could just use byte pointers to the array for next/prev.
• 
  
• The index i in the function that selects the period is always equal to the period value that is chosen.  Just get rid of this column in the array to save memory and pass in the index as the period.
• 
  
• Keep track of how much time we were in power down and just drag the time forward for the tasks once at the end.  Add up each block of time in a variable and make the call with this variable once.
• 
  
• Add different power down mode choices in the library to support various power saving features.  One thing I would need to figure out is which modes need the time adjust for the tasks and which one the timer that millis() needs is still working. Would these various modes choices be compiled in? Or should it be done in runtime.  The runtime option would give the arduino a dynamic processor control but at the cost of a larger runtime for the library.
• 
  
• For the modes where the millis() timer still runs, fix the 50 day timer wrap problem.  Basically everything needs pulled forward back to zero.