Checking the Lathe Bed Ways

On my #534.0601 Dunlap early 1940's wood lathe, I had to have the bed welded (a crack just under the ways on the tailstock end).  The welder (an older gentleman, who has been doing welding for decades) took it and brazed it.  To braze it, he ground the edges, put it over a furnace and heated it up red hot, then added material.  The problem with brazing is that it has to get red hot - which causes cast iron to warp.  On getting it back a few days ago, I knew I needed to check it for flatness to ensure things would be within specs.

However, I don't have surface for checking the plane of the ways to ensure it's not warped - meaning I thought I didn't have the tools to do it.  So, I improvised.  The next best thing was sitting in a gun case.... I had one of those laser sighting tools that sits in the chamber.  I grabbed that, threw it into the drill chuck on the headstock, and slowly adjusted it until I had it spinning without any run out (I hand turned the spindle - I didn't want it too fast).

This gave me a line-of-center from the headstock through the rest of the lathe.  I tossed on the tailstock (closer to the headstock) :

I aligned the tailstock with the laser, and then adjusted the extension on the tailstock to make sure it was lined up.  It looked great.  I slid the tailstock back a little bit, and checked it again.  I repeated this process multiple times until the last 4" of the ways - and saw some drift.  There was some slight warping from the heating.  I should have used a scraper to remove the warp, but I instead used a bastard file.  It took a couple of runs at it before it brought it back in line (it was about 0.05" off).  I am now the proud owner of a completely operational 534.0601 wood lathe with the metal turning attachment.

Memory Leak, Alarm Server, and Valgrind

Note - the output listed here comes after the process was followed, so you won't see the real memory leaks.  Sorry I didn't retain them for posterities' sake.

I had a problem.  My alarm server was having some major issues, and would stop functioning at random times.  There was no core dump to look for crossed signals (no odd null-termination things that I am used to).  However, after a little digging, I found that the process was getting sniped - meaning the Linux kernel was killing it - because it was running out of memory.  Not cool.  I didn't really know how to go about fixing the problem, so I band-aided the thing by putting a cron to reboot the device once-per-week.  I ran with it in that configuration while working on other priorities for a couple of months.  Also not cool, but it kept the security system online while I went and handled my growing project list.

So, I started researching ways to isolate the memory leaks.  One tool stood out as the best one to use (command-line based), and would work with a natively-compiled ELF binary.

Valgrind

Val grind does a lot of things, and memory leak detection is just a small slice.  I downloaded the source, and compiled and installed it (using the standard "./configure && make && make install" stuff).  I did many Google searches, and finally came up with the following command to launch the server inside of Valgrind for memory leak detection :

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --track-origins=yes --read-var-info=yes ./eventserver/server/eventserver -bf ./eventserver/server/eventserver.conf > valgrind.log 2>&;1

Essentially, I wanted to track everything related to memory interaction - I was (after all) looking for a memory leak.  I wanted to see if this would help me identify the issue.  I ran with it in this state for a while (in a screen session, to be precise) to let it build up stats.  When I hit control-C on the application to terminate, I opened up the valgrind.log file, and found a few stanzas similar to :

==12262== 891 (108 direct, 783 indirect) bytes in 9 blocks are definitely lost in loss record 86 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0xAA59: eventserver_key_set (config.c)
==12262==    by 0xAB55: eventserver_sensor_create (config.c)
==12262==    by 0x4D4DDA9: arduino_handle_request (arduino.c)
==12262==    by 0xC795: eventserver_process_hook_socket_handle_incoming (process.c)
==12262==    by 0xDC0D: eventserver_main_connection_handler (main.c)
==12262==    by 0xE29D: main (main.c)
==12262==
==12262== 65,550 bytes in 5 blocks are possibly lost in loss record 91 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0x4DA5A23: my_malloc (in /usr/lib/libmysqlclient.so.16.0.0)

Not sure what I was looking at yet, I knew it looked similar to a gdb stack trace.  The unfortunate thing was that in the traces I was looking at, it was finding things allocated using malloc, and memory pointer problems using strchr.  Since the files referenced called the functions numerous times, I didn't have much to go on.  I went back to Google, and found some additional information.  Apparently, using some compilation flags to gcc, you could add gdb debugging information, such as line numbers.  I manually added the following to the CFLAGS in all of my make files :

-g -O0

The -O0 (capital "O" and the number zero) are an optimization flag that means "don't optimize anything, seriously, leave a lot of junk in the binary" (I swear that's what it says in the man page for gcc).  The -g option means "add gdb debugger information".  You can run with a -O1, and that gets you close to the line numbers, but might not always be accurate.  However, -O0 runs molasses-slow, so use sparingly.  I thought I'd do it anyway.

I started the application again, let it run for a few days, and broke out of it once again.  This time, I had line numbers in the output.  Hallelujah!

==12262== 891 (108 direct, 783 indirect) bytes in 9 blocks are definitely lost in loss record 86 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0xAA59: eventserver_key_set (config.c:219)
==12262==    by 0xAB55: eventserver_sensor_create (config.c:256)
==12262==    by 0x4D4DDA9: arduino_handle_request (arduino.c:228)
==12262==    by 0xC795: eventserver_process_hook_socket_handle_incoming (process.c:257)
==12262==    by 0xDC0D: eventserver_main_connection_handler (main.c:494)
==12262==    by 0xE29D: main (main.c:669)
==12262==
==12262== 65,550 bytes in 5 blocks are possibly lost in loss record 91 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0x4DA5A23: my_malloc (in /usr/lib/libmysqlclient.so.16.0.0)

This was great news!  Suddenly, I could look back through the stack traces and find out where things were happening.  The application initially identified a couple hundred memory leak contexts, and a couple hundred memory errors (seen with the "definitely lost in loss record ## of ##").  On research, I realized that the vast majority of these all had a fairly similar stack trace and line number (maybe one or two lines off).  I opened that file and jumped to the line number and.....

... I had the wrong variable I was using to allocate a chunk of memory.  I made the fix, re-compiled, and had instantly narrowed down the memory error contexts to about three basic memory errors - things where I was using NULL-termination-requiring functions on variables that may not have had the termination and a MySQL error leak.  I fixed the NULL-termination errors, recompiled yet again, and had only the MySQL memory leak (appears standard with that version, which is very old). No more memory leaks!

Security Cameras are Pointless

Sometimes, having a security camera is pointless.  Here is one of those times :

If you can't prevent the hurt from your eyes, how do they help?  Thanks for the laughs, Jeff and Mike!

Bringing Compassion (Ashley Madison)

In June of 2015, a breach of security happened with a company called "Ashley Madison" - a purveyor of cheating spouses, secrets, and probably a lot of illicit behavior.  Under request of someone I know, I obtained the data from that event, trying to run a little bit of profiling.  The data (compressed) occupied over 10Gb.  That is a lot of data.  It expanded to about 20Gb.  That is a ton of data.  When I imported into a temporary database, it expanded to around 45Gb of data.  Yes, 45Gb of damning, dark data.

Curiosity got the better of me and I wanted to do some statistics on it.  So, I tried running a few numbers.  In the process of running a few numbers, I accidentally forgot to pipe the data through the counting mechanism on a single command (I did not make that same mistake again), and it started dumping names to the screen.  As I frantically smacked "CTRL-C" over and over and over in an attempt to cancel that, I was unfortunate enough to witness a few names scroll past.  These were people that I knew.  These were people that I had full respect for one week ago.

That happened two days ago.

I cannot get that out of my head.  As much as I'd like to say that I am not judging, deep down I can just feel the results of their heavy falls from the pedestals on which I had placed them.  The reverberations of simply knowing someone elses sin can lead to two reactions:

• Throw stones at them (stones could be ridicule, insult, or even turning away from them)
• Give them a little room and allow them to try and pick up the pieces of their lives

Now, what do you do when you know this?  How do you react?  The age old question, what would Jesus do?  It brought to my mind the incident of the Savior, when the woman that was caught in adultery was brought to him.  There were two teachings that came about when this occurred:

• No one is without sin, so be careful about casting the first stone
• If you are the one caught in it, stop doing it.

So, how should we be reacting?  Do you want to be the first to cast stones?  Or even the last?  I grew up at dear old Davis High School.  I hated high school.  I was an outcast.  I know what an outcast feels like.  I have been there.  I have experienced it.

Here are some numbers.  In Kaysville, Utah (population of 28,000), there were 932 credit card transactions.  Of those, there were 140 people caught up in that in the city.  In Centerville, Utah (population 16,600), there were over 900 people caught in the data leak.  In Bountiful, Utah (population 43,000),  there were over 1200 people caught in that.  That is well over 2 thousand people that many call neighbors, friends, or family that fell victim to the desires that should be kept between husband and wife.  That is the fall of Helaman's 2000 stripling warriors.

As these people begin to pick up the pieces of their lives that have just crumbled to the ground in a big pile of crap, please take time to do a few things :

• Give them a chance to change.  The Savior did that very thing so many times.
• Remember that they are now fighting a battle that we have never even imagined.  It is resulting in life-ending suicides, divorces (and future divorces), and shattering of everything they have ever known.
• Please bring compassion to the table.  They are going to need as much compassion as they can get.

I am personally grateful that I know the Savior's atonement applies to everyone, including those caught in the Ashley Madison leak.  We need to remember that at the judgement of God, our own "Ashley Madison" data leaks will occur.  Even now, every bad thing we have done is already known.  We cannot hide that fact.  It all comes out in the end.

So be kind.  They get to experience a little of that judgement earlier than we will.  And we will experience it.

3D Scanning - Proof of Concept

Just as a test, I grabbed the Skanect software, an adapter for the Kinect 360, and the sensor from our Xbox. I wanted to see if I could scan something in. The best thing I could think of quickly was the broken down tiller.  It didn't turn out too bad!

https://drive.google.com/open?id=0B-DqTExptE5aRjBXTnZOUG1GaUE.

I also exported it and imported into Blender :

A try at embedding it in the page (might take a while to load, since it's 57.3M) :

Lathe Compound Slide Refinished

I received the compound slide for the lathe yesterday, and promptly (of course, after mowing the lawn and spraying herbicide all over the lawn to try and kill the weeds) set to work cleaning it up and refinishing it.

The first thing to do was to take it apart.  Yeah, you read that right.... I want to take it apart, and there are two reasons for that.  First, I want to have every part cleaned - no old grease, no rust, no dirt, no old metal flakes in there.  Second, I repainted the lathe, and it would be fairly nice if the tooling matched.  So, off I go.

Surprisingly, it only took a few minutes to have it in pieces.  I already knew the carriage (the bottom casting) for this lathe matched the right part number (L2-51).  I didn't know if the rest of it matched up.

The swivel slide (the second cast iron piece) did match up as well (L2-52).   It is separated from the carriage (L2-51) by way of the compound rest swivel (part 9-301):

I could not validate that casting as it was aluminum, and had no part number stamping.  Riding on top of the assembly is the tool post slide, part number L2-53 :

While apart, I wanted to know if the tool post slide could be replaced with something that would allow me to use the lathe as a simple mill.  It's a nice angled mechanism that keeps things in a solid state, so there is no reason why we can't :

Once I had it apart, I threw some acetone at the parts to clean the old paint off.  This took the longest chunk of time.  I had already picked up some self-etching primer from Sherman-Williams, so I masked off the surfaces that weren't painted with machine gray, and sprayed primer all over.

I used two coats of primer, and then sprayed three coats of Sherman-Williams blue.  I had used the cap that was a close match to the original blue (the cap was slightly lighter in color, but you know, that "cap indicates color" thing means it should be close enough).  Unfortunately, the final blue was more of a sky blue.  Yeah, the cap color was half way between the original blue and the color of the sky.  Still, it doesn't look too bad :

While at it, I dismantled the tool rest, the tailstock, and the headstock for the lathe, and cleaned up and painted them.  The only thing left to refinish is the lathe bed.  I can't test-fit the tools to the lathe bed, either, because I just don't have it right now - I had sent it off to a good ol' welder to braze a crack.  But, as soon as it comes back, it will be time to take the labels off the bed, strip the paint off, and refinish that, too.  Then I can put it back on, and find a milling attachment for the compound slide.  Woohoo!

Shop Footprint - Lathe Table Hack

I don't have a lot of room for a "shop".  Actually, I do have room.  It's about 5'x10'.  That's not a lot of room for anything but storing tools, not actually using them.  As a result, I'm all about trying to reduce my "shop" foot print.

One thing I've acquired is an old Craftsman wood lathe (becoming a wood/metal lathe).  It came with a table under it that was fairly solidly built (half-square steel channel, welded together) - about 2'x4'.  There is a problem with the table ... it's heavy.  So much so that it is a bear to move to where I can use the lathe, and then put it away.

So, I opted for the next-best thing.  I welded a steel square tube to the feet, drilled holes, and painted it.  It allows me to throw caster wheels on when I need to move the thing around, and take them off when turning.  Sometimes, I amaze myself (you should be thinking, "if that's all it takes, there are probably issues there).

While I was at it, I welded some angle iron to the frame, and riveted a chunk of peg-board up.  That allows me to keep my tools with the lathe, without them being in the way.  I also riveted a hinge (simply a "custom angle anchor") and another piece of peg board up, and had a sand-paper storage on the tool "rack".

On the other side of the peg board, I riveted a plastic storage container down to hold spare chucks, spindles, etc.

I also grabbed some 1/16" wire "rope" (cable), and connected a hammer, a wooden "mallet surface" (something I can hit with the hammer and not damage tooling), and a printer rod...

... wait, what?

Yeah, a printer rod.  I took a printer rod, cut it down to size, and, since it had a hole in one side, I cabled it up to the lathe.  It is a perfect size to slip inside the headstock spindle and is used to drive out the Morse Taper #1 (MT1) bits.  Since it's cabled to the table, it's always available.  Now my table is complete, mobile.  The next task is to add some adapters to add a lead screw, making this a complete metal lathe with a compound slide.  I already sold my AK47 - the funds are helping purchase a 3D printer! Can't wait!