Finally!

Well, after much time not working on this thing, I have the time and drive to do it. So, got down to business.

The RepRap, when we last left it, was in a mostly working state. Aside from the temp controller. After chasing down the odd issues revolving around problems with it not able to hold temp correctly, I really got serious about looking for issues. I finally found a problem in the power signal coming from the supply. It appears that the cheap Chinese power supply we ordered was indeed cheap, but also noisy. As you can see in the following video, the oscilloscope shows huge spikes and changing noise on the line as the thermocouple turns on and off. I should mention that this reading is on the thermocouple itself, not on the output of the power supply, even. It was creating huge amounts of noise.

I had a 0-15VDC 40A capable power supply (yeah, big) hanging around, so I decided to give that a shot. Hooked it up and the noise was gone, and the temp controller is much more stable now. It still fluctuates a couple degrees between when the heater is on or off, but it's within the limits of the controller's abilities to hold it mostly stable, so I decided to just go ahead and proceed with getting it up and running.

To start, I got a copy of RepSnapper and compiled it, and gave it a test STL and after much playing around trying to get the machine actually talking, I finally got things moving, and made a test print. It's not much to look at, but it's a print.

After this, I began working on Skeinforge to get it to make a decent gcode file. I had issues getting the plastic to stick to the cold kapton and aluminum, so since I already had a heater mounted to the aluminum, I set up my other temp controller and an SSR to control the 110v going to the bed heater. It heats up in about 20 seconds. Things started sticking MUCH better after that.

Following getting things to stick, I tried a few calibration squares, then a ring from Thingiverse to see how good it was working. The calibration cubes are coming out mostly squared up nicely, though I'm having some issues with flow rate. I think I'm not putting enough pressure on the filament in the extruder and I'm having issues here and there with it stripping out occasionally, usually due to the FTDI cable not being hooked up when the stepper controllers are powered on. If the enable line floats and so does the input, the steppers will drive all crazy until they're pulled in a certain direction by the motherboard. Here's a video of building one of the rings:

Last night I tried printing a few more rings as well as an object someone in the lab had tried to make (a mixing paddle from a bread machine) and it did a decent job, albeit with flow problems again. I printed a pair of tweezers as well. So far, so good. A few pieces of the machine aren't tightened up properly and they're falling off, but I'm keeping it together. I'm going to build  my own small control board and mount for the Omron controllers, and finish getting the wiring cleaned up. I'm looking at making one of the new sexy Wade's derivatives that popped up on Thingiverse recently:

 

It's got better accessibility to the hobbing as well as a better gear ratio and smaller styling. I'm excited to start printing stuff on this thing! Hopefully the blog will be going a bit faster now that we've got some activity!

Active Directory and BackupPC

This post is going to be slightly off-topic. Mainly because it's the best place for me to put this information.

When I spend a couple days getting a particular setup to work properly, I feel I should post about it as many others have to help someone out who's in the same boat. So, without further ado, here's how I set up BackupPC to work on my corporate network using ADS authentication.

For this setup, I'm using Ubuntu Lucid Lynx 10.04 Server 64-bit with the latest packages as of 7-14-10. This includes BackupPC v3.1.0.

My setup is this: I have the Ubuntu box (backuppc-srv) running as a VM on a local server. For all intents and purposes, this should not change any configuration as it's bridged networking. We have a set of Windows XP machines that need to be backed up. All machines including the server are joined to the corporate domain (Contoso) and have a FQDN of (contoso.test.com) I have a domain account that has the ability to create computer objects and join machines to the domain, however, I do not have console access to the domain controller. This will come into play later when we create the keytab.

The Ubuntu help sites have started recommending using Likewise to join the domain. While this is easy to do with a desktop, while trying to get Kerberos working, I had nothing but problems with it, and eventually removed it and decided to go about it with straight Samba. It's actually not that hard, and just requires a little work.

We first need to set up the machine to join the domain. I used this excellent blog post here which I will use several commands from to illustrate the process.

As the linked article mentions, it is very important to have a good working DNS setup on the domain. ADS relies heavily on it for authentication and will not work without being able to do forward and reverse lookups. Also, make sure that your machine has good time synchronization. Chances are, if you have a Primary Domain Controller (PDC) it will also be running as a time server. You should be able to use ntpd or ntpdate to synchronize time, which is also very important to Kerberos, as it is normally configured with a narrow clock skew. More than a few seconds difference and you can experience some issues.

To start, this command can be used to install the requisite packages to run Kerberos and Apache authentication:

backuppc-srv:~$sudo apt-get install apache2-mpm-prefork libapache2-mod-auth-kerb krb5-config krb5-clients krb5-user samba-client openntpd

Now that we have the packages installed, we need to setup Kerberos to authenticate to the proper domain.

Edit the /etc/krb5.conf file with your favorite text editor and start looking around. By default there are a few comments that may or may not be helpful. Here's how mine is:

[libdefaults]

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        default_realm = CONTOSO.TEST.COM

Under the next heading you should set up your PDCs.

[realms]
    CONTOSO.TEST.COM = {
        kdc = pdc.contoso.test.com
        master_kdc = pdc.contoso.test.com
        admin_server = pdc.contoso.test.com
        default_domain = contoso.test.com
    }

Now that those are set up, put in the last couple bits here to make things work right:

[domain_realm]

.test.com = TEST.COM

.contoso.test.com = CONTOSO.TEST.COM

Now those are out of the way, we can test the Kerberos setup by using kinit. domainuser is the name of some user account who is in the domain and enabled, i.e., it works on other machines.

backuppc-srv$ kinit domainuser
Password for domainuser@CONTOSO.TEST.COM:

Once you've done this, you can check to see if it issued you a ticket by using klist.

backuppc-srv$ klist
Ticket Cache: FILE:/tmp/krb5cc_0
Default principal: domainuser@CONTOSO.TEST.COM

Valid starting      Expires            Service Principal
07/14/10 12:00:15   07/14/10 00:00:25  krbtgt/CONTOSO.TEST.COM@CONTOSO.TEST.COM

Now we see that the account has been issued a ticket. You can then release the ticket with kdestroy:

backuppc-srv$ kdestroy 

Now we can setup Samba. Edit the file /etc/samba/smb.conf. These lines will be scattered throughout the file, if they're not there, just put them in the general section.

netbios name = backuppc-srv

realm = CONTOSO.TEST.COM

security = ADS

encrypt passwords = yes

password server = pdc.contoso.test.com

workgroup = CONTOSO

You should also add the keytab settings for completeness:

keytab method = dedicated keytab

dedicated keytab file = /etc/krb5.keytab

Now we can join the computer to the domain. Domainadmin is a user on the domain who has privileges to join a computer to the domain.

backuppc-srv$ sudo net ads join -U domainadmin

It will do several things which will eventually end up joining the computer to the domain.

Now you should ensure your /etc/hosts file is setup correctly. It will have your computer name (backuppc-srv) linked to your localhost as such:

127.0.0.1 localhost

127.0.0.1 backuppc-srv.contoso.test.com backuppc-srv

You need to add another line to this with your server's IP address. 192.168.1.123 is the IP address of backuppc-srv

192.168.1.123 backuppc-srv.contoso.test.com backuppc-srv

When this is all completed, we can now get a keytab so that Apache can use it to authenticate against the server. As the linked article mentions, a lot of the tutorials on the web mention using ktpass on the windows machine, but you don't always have access to that, or a secure method of transporting the resultant keytab into the linux box. Luckily you can just get Samba to get one right off the PDC.

backuppc-srv$ sudo net ads keytab add HTTP -U domainadmin

This will get a keytab, and put it into the default file specified in the krb5.conf file, which is /etc/krb5.keytab in this example.

You can now verify that the keytab was successfully retrieved by using klist.

ktutil: (the last command is a lowercase L)
backuppc-srv$ sudo ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l


This method is much easier than typing all that stuff and was just recently brought to my attention:
 
backuppc-srv$ sudo klist -k /etc/krb5.keytab

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1   13 HTTP/backuppc-srv.contoso.test.com@CONTOSO.TEST.COM
   2   13 HTTP/backuppc-srv.contoso.test.com@CONTOSO.TEST.COM
   3   13 HTTP/backuppc-srv.contoso.test.com@CONTOSO.TEST.COM
   4   13            HTTP/BACKUPPC-SRV@CONTOSO.TEST.COM
   5   13            HTTP/BACKUPPC-SRV@CONTOSO.TEST.COM
   6   13            HTTP/BACKUPPC-SRV@CONTOSO.TEST.COM

This shows that there are the proper entries in the keytab.

You need to then give permission to Apache to read the file.

backuppc-srv$ sudo chmod 740 /etc/krb5.keytab

backuppc-srv$ sudo chgrp www-data /etc/krb5.keytab

Now it's time to get apache working. You can use the command a2enmod auth_kerb to ensure that mod_auth_kerb has been properly enabled.

Now we need to edit the backuppc Apache configuration to tell Apache how to authenticate users.
The file to edit is located in /etc/apache2/conf.d/backuppc.conf
This is how my file has been setup. I have commented out the four lines at the bottom there, leaving the require valid-user line in place. I added the six lines at the top.
 
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealms CONTOSO.TEST.COM
Krb5Keytab /etc/krb5.keytab
KrbMethodNegotiate On
KrbMethodK5Passwd On

# AuthGroupFile /etc/backuppc/htgroup
# AuthUserFile /etc/backuppc/htpasswd
# AuthType basic
# AuthName "BackupPC admin"
require valid-user



Now that apache is setup, make sure you restart it (sudo /etc/init.d/apache2 restart), or perhaps better, reboot at this point, just to make sure the domain join is working properly. After it restarts, try to access the backuppc web interface. If you are getting the Kerberos login prompt, login with your domainuser name. No domain prefix is required as it's set to logon to a specific domain and Kerberos on linux cannot handle cross-domain logons.

If you are having errors, it's best to tail -f /var/log/apache2/error.log and set the debug level to debug in the /etc/apache2/apache2.conf file to display errors while attempting to login.

If you get a failed to verify krb5 credentials: Server not found in Kerberos database error, that's usually due to DNS issues, double-check your hosts file that you have the right IP addresses and names listed.

Client not found in Kerberos database means just that, it can't find that username. Make sure it's valid on the domain. I found that trying to logon to backuppc using a local linux user doesn't seem to work afterward, maybe I'm not setting something up right.

Wrong principal in request usually has to do with the keytab file. Check to make sure it has the HTTP sections, and if it does, just delete and recreate it with the command above used to initially make the file. Remember to change the permissions back! This has been the fix for the authentication randomly dropping occasionally, for me.

Once you've got yourself logging on via Kerberos, edit the backuppc /etc/backuppc/config.pl file with the proper user settings. I found that i needed to add the domain to make it recognize the user.. i.e. assign a computer with 'user' set to domainuser@CONTOSO.TEST.COM and that should work when they authenticate. You can also add a user into the CGI admin group in the same file, in the same way to allow that user to have admin access.

You will need to make a modification to the samba command that BackupPC uses if you back up with a local user account that's on the computer and not on the domain. On the Xfer tab of the BackupPC config, just before the -U $user, add -W $host. This will tell Samba that the username you're specifying is for the 'local host' domain, i.e., don't try to authenticate to the active directory, only authenticate locally to the computer. In my case, the local backup user accounts are not valid domain users, so this change needs to be made.

I'll update this when I figure out how to get Single Sign-On working on this through IE6. Right now i'm getting a gss_accept_sec_context() failed: An unsupported mechanism was requested (Unknown error).

Stepper Driver is live!

I brought the completed boards that my friend had drilled and cut out to work, and started the process of populating the board with all the fun components that make it work.

I formulated a strategy, which was to install all the tiny vias, then use the large Chipmaster hot-air machine to flow the large chip and the big current sense resistors on, then solder on all the other smaller SMT components with a hot air pencil, then do the large through-hole components. I chose this mainly because if I were to hot air the large chip last, the air temp would cause many of the plastic pieces on the big components to melt, or blow some of the smaller components off the board.

First power up!

Overall, the technique worked well. I produced a working board with only one small short, which I located and fixed. I then took the board up to FamiLAB, where we tried to hook it up and get it working. The blue light came on, which is power, so we were quite happy there. Then, after fiddling around and finding we had a bad cable, we got it to start stepping!

We got RepRap host up and running and started jogging the stepper around on it, which worked great! We enabled and disabled microstepping, which seemed to also work quite well. All the LEDs and such were running properly, and the chip barely got warm. All good signs. We even took a short video of the first movement here:


Now tomorrow I need to start work on the second one, and I'll have enough drivers to run all the motors. Then it's on to finishing up the electronics...

We have PCB!

So up at FamiLAB last night, we spent some time getting the PCB setup going.. I got some containers to do the PCB etching and developing in, and a few other bits and pieces needed. I started the PCB thing by printing the masks onto paper and holding them to our fluorescent light source to line things up and see how well they would fit.

Fluorescent lights upside-down with glass for registration

Once I had the designs set up properly and it looked good, I printed them out on the transparencies we got. Then we lined them up, used a little spray adhesive on the far corners to hold registration, and opened the board.

The boards are a dark greenish color when you remove the protective sheet from them, the light blue is just a thick film that covers the board that needs to be removed. We pulled it off and set the board in the area we had decided on, and slid it between the glass and under the light. We then set the timer for 8 minutes and exposed each side for that amount of time.

Immediately after developing. Green is the resist.

After exposing, you can barely see the pattern on the board. The dark green has changed to a dark yellow-green, so it's hard to really tell without a bright light, which you can't use yet. Next, you drop the board into a mix of 1 part developer to 10 parts water, and swish it around. Immediately the developer begins to remove the resist and you can see the circuit pattern.


After developing, we needed to actually etch the PCB. We mixed two parts Hydrogen Peroxide with one part Muratic Acid and used that to etch. This stuff fumes pretty good when you mix it, so I'd advise doing that bit outside or in a well-ventilated area. Careful breathing around it or you'll be coughing a lot. We dipped the PCB into the solution and began swishing back and forth by tipping the container. The solution begins to turn green quickly and you can see wisps of material coming off the board, but the process takes about 4 minutes before you see any clear progress. This usually starts around the edges where the copper begins to be completely etched away, revealing the fiberglass board beneath. The total time we had was about 6-7 minutes of gentle agitation and flipping the board every so often.

Final product. Green is stains from removing the resist.

After etching has completed, we rinsed and dried the board, then removed the resist with Acetone. It comes off pretty readily, but also seems to stain the fiberglass. Not a big issue. What's left is ready for drilling and soldering. I used a script in the EAGLE software called 'drill-aid', which takes the large holes normally printed for the vias and components and fills them in, leaving only a tiny 0.3mm hole in the center. This helps with drill centering, I'm told, so I went ahead and used it, and the tiny holes etched perfectly.

The finished product is really good. Although I still would like to get it on the stereoscope at work and take a look at it really up close, everything I can see went perfect. The process was so complete, that even a place where the toner had a few holes showed exactly the same on the board. (The toner is several years old, as is the printer, an HP LJ 2200D.) We're really excited about the possibilities of what we can make with just some simple work on the computer. I'm really interested to try my hand at laying out some boards myself!

Those who have been working with the Stepper Driver 3.2 will notice that the board there is a little messed up. I accidentally mirrored both sides, and this caused the board to be etched incorrectly. Now there's no way to actually make these boards work, so we're calling this our photoresist test board, and we're going to do another using better transparencies, a better printer with darker toner and higher resolution, more accurate registration marks, etc. Hopefully the next will turn out just as good, or hopefully even better than the first!

(There will be a video of the etching process posted tonight, I need to edit it up a little.)

Almost there...

Well, we're still working on finishing up the bits and pieces of the Mendel. Mainly, we need to get the PCBs done for the stepper controllers. My partner in crime ordered some stepper motors and those should be coming in today or tomorrow, and we'll be using those with the stepper controllers to get this thing running.

In my previous post I was talking about the Stepper Driver 3.0 that we were going to be building. Well, I got a short email dialogue with Zach Hoeken and he informed me that the modifications that Nophead suggested were made on the newer revision of the board, which he directed me to. (the XLS file is out of date, schematics are up to date)
So, the only problem is that I ordered all 1206 parts, when the new revision changes up a lot of components for 0805 parts (SMT part sizes). This causes an issue cause the parts I ordered are too large now to fit on the revised board's pads. So, I need to order all new parts, which I did yesterday. Hopefully the LEDs will be nice.. I got a good variety.. Deep Red, True Green, and Hyper Blue. RGB are my favorite colors to have on things.

We got the PCB boards and developer in, and we're going to make some Cupric Chloride to etch the boards. It's much safer than the Ferric Chloride, and better for the environment too. I spent last night working a little in Eagle. The light version won't let you panelize the board because it's too big, so I exported each side of the board as a PDF and then imported it into Inkscape. From there, I created an outline the same size as our board to help me in positioning the sides, then used align tools to create top/bottom layers. Now I can mirror the top layer and print them onto transparencies. We're building a UV light source with a lot of LEDs to see if that will expose better than fluorescent lights. It seems to be pretty sensitive, the package says to expose for 60-90 seconds under "exposure unit" which we're assuming is a UV source. or 6-10 minutes under a normal fluorescent lamp.

I got around to redoing the H bridges on the extruder controller, because I had hooked it up backwards to 12v at one point and blew the H bridges. So now I have a new set of H bridges on the board, so we should be good to go. However, I'm still going to be using the Stepper Driver 3.2 on the board. I may use the 3.2 boards I'm making for the X and Y axises, and the normal ones for the Z and extruder, as they require less precision. The 3.2 boards are tunable via 4 potentiometers and also have selectable microstepping. That will be an interesting feature to experiment with.

I'll try to get some photos or video of the etching process, as I think it would be a cool thing to watch!

Lots of progress!

Well, I apologize for the lack of updates, but we're in a pausing point here, so I will post a bunch of stuff that documents our progress since the last post.

When we last left our hero, he was having issues getting the MakerBot to work properly with the new FiveD firmware. Since then, we've managed to figure out what's up, remove those offending M codes from the file (M101, M103) and get printing again.

I've gotten the Wade's extruder all tuned up in Skeinforge, and it's doing an awesome job printing parts. We've even gone back and reprinted parts during our assembly that were done on the old Plastruder, and they've come out with much better tolerances on the new extruder. I've gone ahead and printed out another copy of it to use on the Mendel, so we will see how it works on there!

The Mendel. Yes, we started construction as we neared just a few parts left, and have gotten it pretty much completely built! There are a few little quirks here and there, like if you're using Josh Updyke's milled plastic frame vertexes, you should add another 1/2 to 3/4" to your x-plane rods. We added more washers to the Z belt bearings to space them out further from the plastic. We created our own M3 set screws with a Dremel, and hopefully have a good hobbed bolt for using on the new extruder!
I've almost finished up the HeatCore for the Mendel, which we'll be using temporarily while I experiment with the cartridge heater and copper block I'm building.

(When I say "we" I mean myself and another friend at our hackerspace, who is also building a Mendel.)

While I originally planned on documenting the entire build by photo, we had forgotten to do this and decided that when we build the second one, we will try our best to document the build process.

Other than that, the build went fairly smoothly. Belts are attached, frame is squared and tightened down, and we got some of the electronics mounted up on it. That's our current holdup. I used one of the stepper drivers in the MakerBot to drive the stepper for the extruder, and the TechZone kit only comes with three. So currently we're at two stepper drivers, and one half-broken extruder controller (I hooked the 12v up backwards and fried the H bridges.. but hopefully we won't need those).
To fix this dilemma, my friend an I have decided to build our own stepper driver PCBs. TechZone will sell individual PCBs, but we decided that it would be interesting to try the new 3.0 driver and see how well it works. We have PCB making supplies, and are currently in the process of getting a couple more things. We're going to go ahead and try the UV method to put down the resist, so hopefully that will work out well.

I've asked around about people using the 3.0 drivers, but all I can find is a forum post saying they'll be available for purchase sometime around February.. Well, it's been quite awhile since then, and the design on the SourceForge hasn't changed in 5 months or so. I'm assuming there just hasn't been any more testing on it. We've got the components ordered up to build 3 of them, and the tools to do all the SMT work. Hopefully we'll be able to get a usable board out of this process. We will also document what we're doing here, cause it's a pretty exciting thing to make your own PCBs and build them!

Aside from that, the axises on the machine are all moving with the stepper controllers we have. The TechZone board did not come with a bootloader burned on the chip, but luckily we had a USBtinyISP that we used to burn one on there. After that and a quick load of the FiveD firmware, things are moving around. We'll do the same for the extruder controller soon and hopefully it'll be running the machine within a week or two! Then we can start tuning Skeinforge again. I can't wait.

(photos will be posted later today)

FiveD MakerBot Mishaps

Well, not to start out unhappy, but I've been working a lot on trying to get this thing to work right. It's not easy, let me tell you. I've had a few successes, but it seems I've run into every problem possible while doing this.

Now I've got my machine set up with the endstops and motor directions (by moving endstops and reversing motor cables) so that from the front, it plots in the same direction as all the software we use shows us things. i.e., origin is closest to viewer, left. (Bottom-left). This helps not build parts backwards, and makes visualizing the platform and x/y movements a bit easier.

The geared extruder is hooked up and running well. Haven't had many issues so far with the extruder itself; as a matter of fact it's gone quite well. The big part has been getting the table and software to work well.

A lot of the issues I had tonight dealt with Skeinforge. I'm using the latest version as of the time of this writing (2010-04-26). The RepRap host software (once I figured out some decent settings, which I'll post tomorrow) works good enough to get out a demo print. It's not perfect, but it will build an object.. roughly.

The objective here is to use Skeinforge's Gcode creation to build objects, since it's much more developed than the other. We still use RepRap Host software to send the gcode to the printer, but Skeinforge is doing the creation. I'd like to try/use RepSnapper soon, but it has issues with the 3d on this laptop.. seems the Intel drivers on here aren't really up to par for 3d stuff. We'll have to wait until they fix that. It doesn't run all that hot in the VM on here.

Had an issue earlier with the Z axis not working correctly. Turns out, Skeinforge's Z feedrate needs to be set quite low.. mine's set to 1.5mm/sec. Set anywhere higher and it freaks out a lot..

My main problem was that I had issues with it doing odd things.. I tried printing calibration blocks, but they definitely were not correct, and when I tried printing a 20mm solid block, I knew we had an issue.. Here are the photos:

Three calibration blocks. That triangle is there instead of the second shell on the other two sides..

20mm solid calibration block. This one's outline was extruded as huge blobs in the corners for some reason.

With these two, they have very different and odd issues. Mainly, the extrusions are not working properly. Visualizing the Gcode in RepSnapper shows that the code is proper.. somewhere between the code and the machine, something's not getting interpreted correctly.

So I did some investigating.. I loaded up the same object in Skeinforge and RepRap Host, and generated gcode files, and tested printing them. The RepRap Host file printed properly, and the Skeinforge file didn't. I then opened up the Gcode files side by side and tried looking for differences between the two.

In the Skeinforge file, whenever the extruder starts and stops, the file issues M101 and M103 codes. These are extruder start/stop commands, usually used with DC gearmotors. They tell the controller "start extruding, stop extruding" all at the preset speed. However, with stepper motor extruder drives, the extruder is treated as another axis, and therefore does not need on/off commands, as the stepper routines and controller take care of positioning the stepper appropriately.

One would think that these commands would be ignored, then. However, the RepRap Host file did not contain these codes. When I removed them from the Skeinforge file and reprinted (using the RepRap Host software), the file printed properly. I don't know what is causing this, the firmware or the host software, but one of the two just can't seem to handle those codes when it's using a stepper extruder. I used a simple find/replace command to delete them, and the files Skeinforge produces are working now.