Fun with bed leveling on my cbot

So, my latest exploration is the cbot 3d printer. This makes 3d printer #5 or so for me so far. The first printer was pretty much terrible but I learned a lot. The second was a lot better but still really not accurate. The 3rd printer ( a Mendelmax 2 from makerstoolworks ) rocks and I still use it almost daily. The 4th printer was a kossel mini which I decided against - just was not going to be stable enough for my needs.

Up until my attempt at the kossel I have lived with just normal old school manual bed leveling. For the most part its still the best way to go but the idea of a probe near ish to the hotend to get things fine-tuned has been growing on me. I still don't view it as a good idea to run before every print - things just should not change that much to require constant probing ( or your printer is just shit - sorry ).

So far the only methods I have tried involved microswitches. My biggest complaint with these is the trigger pressure and movement speed. Sure it works fine for your X, Y and maybe even the Z axis though I admit I don't like the run of the mill microswitches. The variance I have noticed in the z min switch has been enough to actually make a difference - the kind that fails the print out-right or worse. I have also tried the IR sensor but those have issues as well - what happens if the light refracts funny or the angle of the ir led and/or sensor are off? I've trashed build plates thanks to these damn things!

On the z min side of things I have recently switched to a different microswitch from omron - the SS-5-FT to be exact. They have a 50 gram trigger force vs others that are 150 gram or higher. So far this switch is great - I've actually been getting reliable results to date and I've had ~200 print hours with them so far - probably 30 or 40 prints. The other option is to use either a hall effect or optical sensor both of which I have and have tested off box. On a funny note I found a really neat use for those old banned buckyball magnets though I have not yet set that test up.

My latest foray into the probe based tuning centers around the BLTouch. This is actually a really sweet sensor - they did a great job designing it. Super light, small and seems very well thought out. I've had a few oopsies and nearly broke one - bent the pin a little bit and it needed to be 'fixed' ( eg I had to take pliers and bend it back ). Their firmware on the sensor has given a visual indicator ( blink ) when things are not right and has been super helpful.

My printer has a 300x300 ish build plate of which I get approx 285x285 to print on. I put together a set of 5 test plans to execute though now that I am writing this I could add at least 2 more and get some really interesting data out of this. The plan is to use the sensor to probe various points around the bed both on the perimeter and inward towards the center. The idea here is to get a plane and make all probed points within .05mm of each other in terms of travel from a set height to the bed. Once I have a plane figured out ( running all test patterns ) I'll then go tweak the bed and iterate until its perfect. Once this is done the only issue I should ever have to deal with again is the zmin switch - the bed *should* stay level after that assuming nothing is changed or moves on its own.

Note, this is all with a Smoothie board - in my case its the X5 mini v2 from Panucat.

Set 1 probe points
    M557 P0 X250 Y240 ; back right corner
    M557 P1 X20 Y240 ; back left corner
    M557 P2 X135 Y40 ; front ~center

results
    Recv: X:250.0000 Y:240.0000 Z:13.3400
    Recv: X:20.0000 Y:240.0000 Z:13.3237
    Recv: X:135.0000 Y:40.0000 Z:13.4625
    Recv: max delta: 0.122499

Set 2 probe points
    M557 P0 X250 Y50 ; front right corner
    M557 P1 X40 Y50 ; front left corner
    M557 P2 X135 Y250 ; back ~center

results
    Recv: X:250.0000 Y:50.0000 Z:13.5175
    Recv: X:40.0000 Y:50.0000 Z:13.4175
    Recv: X:135.0000 Y:250.0000 Z:13.3438
    Recv: max delta: 0.173750

Set 3 probe points
    M557 P0 X40 Y250 ; front right corner
    M557 P1 X40 Y50 ; back right corner
    M557 P2 X250 Y135 ; right ~center

results
    Recv: X:40.0000 Y:250.0000 Z:13.3450
    Recv: X:40.0000 Y:50.0000 Z:13.4362
    Recv: X:250.0000 Y:135.0000 Z:13.3500
    Recv: max delta: 0.091249

Set 4 probe points
    M557 P0 X250 Y50 ; front right corner
    M557 P1 X250 Y240 ; back right corner
    M557 P2 X40 Y135 ; left ~center

results
    Recv: X:250.0000 Y:50.0000 Z:13.4913
    Recv: X:250.0000 Y:240.0000 Z:13.3438
    Recv: X:40.0000 Y:135.0000 Z:13.4037
    Recv: max delta: 0.147500

Set 5 probe points
    M557 P0 X40 Y135 ; left ~center
    M557 P1 X250 Y135 ; right ~center
    M557 P2 X150 Y150 ; ~center

results
    Recv: X:40.0000 Y:135.0000 Z:13.3663
    Recv: X:250.0000 Y:135.0000 Z:13.3525
    Recv: X:150.0000 Y:150.0000 Z:13.3625
    Recv: max delta: 0.013750

Now, the probe points themselves are a little strange - the nozzle will bump into the build plate clips so I have to move things out a bit. I could fine tune the probe points and I probably will. Also note the probe is offset from the nozzle tip by -32.11 on the X and 38.96 on the Y.

The Z value aver each Recv line is the distance traveled to trigger the probe from an original height of 15mm.

My basic script for each of the probe points is as follows:

M280 S7.0 ; raise the probe
G28 ; home all
M114 ; print current positions
G1 Z15 F3000 ; move Z to 15mm
M280 S8.4 ; run BLTouch self test
M280 S5.5 ; enter zmin mode
M280 S3.0 ; drop probe pin
G29 ; run the plan
M280 S7.0 ; raise the probe

Before running that script I issue the M557 probe point lines. You can check these with M503 - the probe point defs are towards the end of the output.

So far I've been able to prove what I kinda already knew - the right front of the bed is a little low. I've found that I can print pretty well on the far left of the bed and back 2/3 of the bed though I do get some differences in layer squish. As I said above the plan is to use the sensor to very finely tune the plane of the bed. Its very likely I will unhook the wiring or even remove the probe when I'm not actually using it.

I have found the smoothieware.org zprobe doc very helpful. Minor note, on the X5 mini you need to switch the jumper to 5v instead of 3.3v power on the endstops. The normal smoothie is only 5v last I checked - the bltouch lights up fine but you need 5v to get the probe to go up/down.

mysql

you suck, that is all ;)

mysql> update user set Password = '*' where User = 'foo';
Rows matched: 3  Changed: 3  Warnings: 0

mysql -u foo -p


Access denied

mysql> FLUSH PRIVILEGES;

mysql -u foo -p

mysql>

*head hits desk*

yubi key + pam

So,

Decided to play around with multifactor authentication setups.

A friend of mine suggested I try out the yubi keys and a central auth system. I went ahead and sprung for the yubi neo which is an nfc-enabled yubi key vs just the standard usb key. Thought it would be more interesting in the future but I really only needed the usb key.

My main interest was to set up stronger auth for my home network. Not because I need it but because I can ;)

Simple requirements:

1. multi factor passwords
2. allow me to use local validation ( say laptop without net access yet )
3. simple to set up/use
4. additionally use for my vpn ( openvpn most likely )

So far I have set up basic authentication on a VM. Simple pam auth using the yubi cloud auth servers. I'm not convinced it set up 100% the way I want it as you can bypass the authentication via ssh if you use ssh key auth. But, that does seem interesting - can have both.

The setup docs on https://github.com/Yubico/yubico-pam/wiki/YubikeyAndSSHViaPAM got me about 90% of the way there. The setup doc is short a few things.

1. You need to get an api key, https://upgrade.yubico.com/getapikey/
2. The response contains the id and an api key pair which you need to configure in your pam config. Here is my pam config
   
   auth required pam_yubico.so id= key="" mode="client" authfile=/etc/yubikey_mappings
3. They tell you to set ChallengeResponseAuthentication to no but you actually want yes

Once I got everything configured, logging in and using sudo all prompt for my yubi password ( your standard password + hit the button on the card ) for access.

$ ssh 172.16.189.140

Yubikey for `bilsch':

Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-23-generic x86_64)

bilsch@yubi:~$ sudo bash -o vi

Yubikey for `bilsch':

root@yubi:~#

Still want to verify this is set up right. I still like the idea of having ssh key auth but for certain special boxes/host types this seems a pretty great setup so far.

sensor monitoring with arduino and raspberry pi

Thought I would change my experiment a little bit. Previously I had grabbed the DHT22 from Adafruit and hooked it up to my raspberry pi. This worked fairly well and with some modifications to their driver code I was getting fairly reasonable stats albeit running in to a minor driver issue ( getting stuck in an unbounded loop )

In the mean time I've been thinking about how I would want to handle my remote temp/humidity sensors project. The main idea so far is to put a sensor in every room and aggregate the data in to graphite ( via collectd ). The cost of the sensor plus the heft of the full linux box for a simple little sensor started bugging me - the sensor side of things is actually better off running on something like an Arduino - its very low power, commonly available and flexible enough to do what I want in the long run. Sadly, for the price/power ( cpu/memory ) the difference in price is kinda off but the platforms really are rather different.

I probably went overkill on the arduino side - picked up an R3 Mega - an Uno or maybe even the Micro may be better suited but I grabbed the Mega as I have other projects in mind for the future and thought I'd get this instead.

Adafruit has another tutorial for the same sensor but on an Arduino including a driver ( and looking at the source, I think their pi version was based off of this code ). Setting it up on the arduino was surprisingly very very easy!

The idea is to read the sensor metrics via serial ( eventually switching to XBee for RF/wireless <=> serial. For now, I'm just using jumper wires from the Mega in to the serial port of the pi ( Serial1 on the Mega )

I found a few interesting things:

1. The Serial.read does not block as I thought it would/should
• Idea was to control the collectd Interval from the exec/c code - can't do that ( at least not yet )
2. Even though I don't do a Serial.setup() trying to write to Serial1 blocks unless I have a usb connection from the hub ( which is powering the Mega ) to some system. Not sure what that is about

The driver code is fairly simple. Basically just a very slightly modified print statement to only print the temp/humidity over the serial port. On the pi I have a little ruby script exec'd by collectd which is in a read loop and ( admittedly rather blindly ) spits out the values:

while 1
  stats = sp.gets.chomp.split()
  if stats.size > 1
    temp_c   = stats[1]
    temp_f   = ( temp_c.to_f * 9 / 5 ) + 32
    humidity = stats[0]

    puts "PUTVAL \"#{hostname}/sensor-basement/gauge-tempc\" interval=10 N:#{temp_c}"
    puts "PUTVAL \"#{hostname}/sensor-basement/gauge-tempf\" interval=10 N:#{temp_f}"
    puts "PUTVAL \"#{hostname}/sensor-basement/gauge-humidity\" interval=10 N:#{humidity}"
end

So fairly simple and like I said, its rather blind but I control the input to some degree and collectd will whine if the data is not normalized

Next step is to see if I can find/assemble the right sized arduino/case and find a way to get a connector for the sensor so I can swap it out ( and not get funky/false readings ) and get some of the XBee chips to play with.

puppet on the pi

Well, a follow-up of sorts on the raspberry pi and puppet posting from a while back

Thought I would post the code up on my github account, https://github.com/bilsch.

Tried rebuilding from a fresh image. Other than burning a lot of cpu time on puppet installation itself ( think I have a fix for this one, don't generate rdoc/ri ) the fresh install to a running pi where I essentially want it. Everything worked fine except for the fimware/boot rom update which is just another git clone/copy.

itunes11 and ebook pdfs

So, Apple in their (in)finite wisdom made a few changes in itunes 11. Among them, something to do with pdf/ebooks and the book library.

It seems you can no longer add purchased ebooks ( at least, not sure how far down this goes ) to your library. The change occurred in the crap-tastic itunes 11.

The best part is the recommended solution: Go download/install the Kindle iOS application and use its doc sync features to sync up the pdfs.

WHAT?!

The other odd part is that the pdf/ebooks ( from the same vendor, Manning ) which were already in my library are fine - still there and still able to read them/sync to iphone/ipad.

Apple, why have your software products taking a nose dive these last few months? Wake up!

I think Apple may be telling us to not only use other people's software but maybe even switch to their hardware?

Raspberry pi puppet

So, I decided I really wanted to have an easy way to get my raspberry pi images to a somewhat sane state but I did not really want to write shell scripts to do this.

I've been using puppet at work for over a year now and its pretty simple really - most of the time I spend on puppet configs is debugging various isms ( like, for an ssh authorized keys manipulation, you can't throw an array to user :-< )

Planning to test out my image process soon-ish. Still need to get mcollective working properly - think its about the last module still erroring out on me.

So far, I have:

1. ssh configuration
2. various package installations
• rasp-config, ruby-shadow, python-pip, ruby-dev
• ruby packages: builder ( for gem installs ), wiringpi
• pip ( python ) package rpi.gpio
3. rsync backup, just a simple backup to my fileserver
4. /boot/config.txt so I can preserve any modifications I may want
5. locales config
6. user maint, putting my ssh key in place, forcing pi's password to be maintained/not raspberry
7. automate git clone of remote repos
   ( So I don't have to remember to do those by hand though updates/pull will be manual )

Only down side is that I'll still need a bootstrap script to put a few packages on the box - puppet/facter gems and puppet.conf, then I should just need to run puppet agent and everything should magically appear

I may upload the puppet configs to github but most of the configurations are going to be local