CNC controller case.

Though I don't think I'll have Apple banging down my door to design their next iHip^TM device, I'm slightly proud of the fact that I turned this:

Into this:

Stainless steel is tough to work with.

Not only does stainless steel foil not cut well, stainless steel plates do not solder well with basic lead-tin solder. resin flux, and a cheapo 25 watt iron.

From the Internet, I have learned that you either need hydrochloric acid, or silver based solder and a much higher wattage iron or even a torch. I don't like using or keeping dangerous chemicals, and HCl is fairly high up in the danger scale.

I attempted to use a butane lighter to heat the stainless steel which I had sanded/roughed after my first failed attempt with an iron. The lead solder formed a ball and slid around on the surface of the plate, resembling mercury. It refused to bond, however.

This is for a probe attachment for my CNC. I've decided to skip the soldering, I will just bend at right angle in a new strip of stainless, and drill a screw hole and attach a lead wire to the screw.

--P

Seeding the standard C random number generator on AVR chips.

The rand() function in C gives your a pseudo-random number generator. To purists, it's got a lot of flaws, but I'm glossing over that for this post. In many cases, it is "good enough" to get the job done. A lot of times, I don't care that the distribution is not strictly even when you do something like.

int foo = rand() % 10;

Many times, just a rough approximation like above is enough to make something "feel random".

The rand() function uses a formula that calculates new "random" numbers based on a formula that includes the previously generated value(s).

So where do you get the "starting point" for the first number in the formula?

The standard C library maintains an internal state for the random number generator, and you can "seed" this state with the "srand(unsigned int)" function.

So what do you pass to it?

Well for any given "seed", you will generate the same sequence of pseudo-random numbers. For instance:

srand(42);
int a = rand() % 10;
int b = rand() % 10;
int c = rand() % 10;

will yield the same sequence for a,b, and c every time it is run. What if that is undesirable? It's almost like you need a random number to seed the random number generator, a "catch 22".

On desktops, seed values are often taken from some system time register, on Linux systems, it's sometimes generated from a timer that measures the time between a user typing keys.

On microcontrollers, you often don't have inputs, and system up-time timers don't work because the time will likely have the same value in the power up initialization sequence.

It can be difficult to get these miracle computing machines to be non-deterministic when you want them to.

A trick you may be able to use, depending on your setup is to use the ADC (analog digital convert) built in to most AVR's (on other brand) micros to read a voltage level on a pin that is "floating" or otherwise not tied well to a particular voltage. Here's a short example of how that looks on an AtTiny85:

#include <avr/io.h>
#include <stdlib.h>


void setup_seed()
{
unsigned char oldADMUX = ADMUX;
ADMUX |=  _BV(MUX0); //choose ADC1 on PB2
ADCSRA |= _BV(ADPS2) |_BV(ADPS1) |_BV(ADPS0); //set prescaler to max value, 128

ADCSRA |= _BV(ADEN); //enable the ADC
ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait until the hardware clears the flag. Note semicolon!

unsigned char byte1 = ADCL;

ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait again note semicolon!

unsigned char byte2 = ADCL;

unsigned int seed = byte1 << 8 | byte2;

srand(seed);

ADCSRA &= ~_BV(ADEN); //disable ADC

ADMUX = oldADMUX;
}

In my case, PB2 was connected to a resistor, which was then connected through an LED to ground. When the pin is in a "high z" state (eg, not driven by the CPU), this approximates "floating" close enough to give me nice erratic values. Notice that I use the "low bits" of the ADC. The low bits represent smaller voltage differences, and exhibit greater variance, so they're more likly to swing a lot on a floating pin.

I'm not sure if it was really needed to scale the IO clock down by 128x, I just added it for flourish, thinking more time would mean more variance. I have no scientific evidence that is true though.

Enjoy!

--P

Updates, random bits.

Here are some things in the works for future posts.

• My Zen Toolworks CNC is nearly complete for CNC functionality. I have all the parts and materials for 3D printing, I just haven't tired to do it yet, I'm still mastering CNC functionality, and tweaking my Marlin based firmware as I realize I want particular functionality.
• I have a complete failed project started and scrapped in the space of two weeks, a record for me. I'll write it up later, but one of my goals was "to succeed, or else fail fast", mission accomplished. I did learn *a lot* though, so it was not wasted time at all.

Here are some things I learned recently:

Excuse me sir, your voxels are showing.

This occurred to me today, as I listened to a podcast at my day job, and the word "voxel" was mentioned, and explained to someone on the show.

Let's play a game.

pixel --> "picture element"
voxel --> "volumetric pixel" or "volumetric picture element"

But 2-dimensional  is to picture as 3-dimensional is to .....volumetric picture?

That just doesn't feel right. Imagine saying, "Hey Sven, that's a nice volumetric picture of The Battle of Gettysburg you built in your dining room, how did you get your wife to agree to that?".

I submit that 2D is to picture as 3D is to model. I don't remember what I got on my verbal SAT, other than it was respectable, and surprising to linguistically challenged dude like myself, but I think that would pass as a feasible answer.

I'd like to propose that henceforth, a three-dimensional counterpart to the pixel be known as a moxel, "model element".

They don't call me Pedantite for nothin'

--P

[UPDATE] After they read this post, ETS contacted me to inform me they are retroactively reducing my verbal SAT score.

Milling Hotend Nozzle Mount

How's *that* for a racy post title!

My Zen CNC is fairly usable now, so I've turn my attention to getting the 3D printer functionality. One glaring task is how to mount the nozzle to the extruder. You know what they say, the 7th time's a charm:

I'm not 100% sure that the most recent one will work, either. But I did actually have a lot of fun designing and figuring out how to design and mill parts. The parts above are ordered chronologically from left to right. #5 and #6 were milled using a cheapo 1/8" "Roto-zip" bit, since I was worried about the wear and tear on my one and only carbide end mill. I also experimented with various feed rates. #5 was milled at 1000mm / minute horizontal feed rate, with the cheap bit. I could actually see the bit flex as it moved.

The result was not pretty, you can see how bad it looks. I also think the bit was probaly not the appropriate shape for the job, cheapness aside.

I'm pretty pleased with the final one:

Ugg, what's up with the shadow? Would it kill me to take a decent picture?

The "burrs" on the edges are non-structural, and rub off with your fingernail, I believe its just an artifact of MDF.

--P

CNC update

I hit a milestone with my CNC project tonight, I made my first cut!

Here's the current state of it configured for milling:

I'm using the Zen Toolworks 12x12 , F8 edition. The F8 edition has an extended Z-axis travel on the gantry, which is needed to be able to use the device for 3D printing. One thing I didn't realize initially were that: 1) configured as a milling machine, the spindle will not reach down to the bed, and 2) the extra Z axis travel does not benefit milling as much, because the gantry clearance is one of the limiting factors. The two possible approaches to address the first issues are to either re-work(ie invent your own) the spindle mount to lower it close to the bed, or to build an elevated platform as your new work area. I decided to do that because it reportedly reduces error due to frame torsional forces. I could always build a new mount and remove the table. The Zen is pretty flexible in that way, a good deal of the design can be up to you.

CNC progress pic.

Just a quick shot of my cnc build in progress, I'll post more about it later. I had a slow start waiting for all the parts, I think I'll avoid ordering big stuff around Christmas next year.
Tonight I'm working on end stops and the y-axis of thr Zen Toolworks chassis.

New Project - CNC/3D printing

While physical computing has captured my fancy the past few years, one thing that seems to have frustrated me is the physical construction for my projects. I have a degree in Mechanical Engineering, though I went into Software Engineering professionally, so that struck me as odd. I think I've grown accustomed, spoiled even, on the fantastic availability of free and low cost tools available in the software world. I'm used to having as powerful tools to develop software as a hobby as the professionals use. Not so with hardware. Things are getting better though.

I've decided to take it to the next level, and I'm investing in a small CNC that will also be capable of 3D printing. I'll document my progress on ByteCruft. (My robot project is not stalled, but I'm putting the CNC project first, since there's a long lead time with getting up to speed.) I currently know very little about milling beyond what I remember from school almost 20 years ago. I expect my progress to go faster than my typical  'epic' level project, since I'm focusing less on trying to do lot of design myself. I'm mostly cherry picking various kits and packages and making them work together.

Zaethira Progress.

I've been doing a lot lately. Often, when I've had a choice between posting something, and working on something, I've chosen the latter. I noticed recently that I missed the month of November entirely, my bad! To top it off, my last post was a bit of a crotchety vent about haters, and we all know haters are gonna hate.

I've been working a lot on my robot autonomous vehicle, Zaethera. I've also got a ton of other projects in various stages of planning, that I'm keeping mum about for now.

In my last post, I posted a color-coded high level view of the architecture. There's a lot more green now, I'll post an updated chart in my next post. I don't think I dropped any subsystem from the original, and much of the left-hand side is built assembled, and ~50% coded.

I'm beginning to enjoy this electronics hobby thing.
The parts in the Sparkfun box in the back are the rear/side
IR proximity sensors, and the compass module. Near the top,
on the red, black, and blue wires is the IR remote control receiver.

Rant time, a very special episode of Bytecruft.

It's rant time..

I know it's so usual for us nerd/engineering types to get cranky online about something, so this may come as a shock....

I came across a post today on Hack a Day today about a guy who got the .Net Micro Framework running on a STM32F4 Discovery Board, something I have done, and briefly mentioned here.

Original link.

Mr [Singular Engineer] did a fantastic write up by the way, I wish that had existed when I was trying to get up and running, it sounds like his experience was slightly smoother than mine.

Anyways, as I read the comments section on the Hack a day article, I felt compelled against better judgement, to reply to some of the general criticisms against the .Net Micro framework. As my reply grew in the volume of prose, I thought, maybe it would be better presented on my blog. So here ya go:

Robot update.

I haven't posted in a while. The lulls usually happen when I'm busy. I've failed you, my adoring fans, and for that I blame... um squirrels..

I have been happily jamming away for the past couple months on my robot, Zaethira. (Which is a concatenation of my kids' and wife's names, and happens to sound geek awesome, the geekiness of the whole is greater than the geek sum of the parts).

Anyway, I could have written a 20 page blog post about how things are coming along, but I think a diagram does a much better job. I made the below because I needed to get a handle on where I needed to focus and what I planned to do. This diagram made me realize how flipping complex this project is.

Introducing Zaethira - One word: Robots

So I've finally gotten around to one of my dream projects. I'm making a robot.

I'm relinquishment a little bit on my must-do-everything-myself approach I've taken to many of my projects, and I'm using some kits and some pre-fabricated circuit boards. After my experience on my Bench Power Supply, I wanted to boost my odds of getting results and focus on the fun stuff. I really think for this project, despite being something very physical, the software is going to be the most fun part, I am a software guy at heart, after all.

Shortest post ever.

I'm not sure why I have not tried to build a robot sooner. Already the most fun I've ever had on an electronics project, and it's still very early in development.

That is all.

--P

Rudimentary benchmarks for the Parallax Propeller.

I'm in the early stages of a big new, ambitious project, that I've wanted to do for a long time. I've got some Propeller chips from Parallax that I've had sitting around for quite a while, so I thought I'd try to incorporate the 'Prop' as one of the many microcontrollers this project will have.

The Propeller is quite a unique processor, I'd even so far as to say it's design is exotic. What it lacks in specialized hardware found in most other MCU's it makes up for with having 8, that's eight, cores. You want I2C, you just dedicate a core to doing it in software. One of the few exceptions is something not found on many other MCU, it's has dedicated video generation circuitry.

A custom language, "Spin" has historically been the primary high level language used on the chip. Parallax has designed into the ROM a byte-code interpreter. You can also use assembly, especially for performance-critical code. C/C++ had for years been an experimental language on the chip, but that has changed in the past year or so. There is a full fledged GCC port for it. I decided I'd give it a try.

Seeeduino Stalker Waterproof Solar kit review PART 2

In my last post, I covered the Seeeduino Stalker board itself, I wanted to get into some of the other aspects of the kit.

The hardware (continued)

Bench Power Supply

I decided to mothball my power supply project. I may come back to it one day, I may not. I sort of had a rage-quit moment this week-end, when I blew one of the channel's regulator circuits. The thing is, I didn't do anything I didn't think it could handle. Now, the voltage output is always 2 volts higher than what I set it for, and the current-limiting seems to never kick in, it goes to 1 full amp (or at least that's the max I'm capable of measuring) when I short it. Meh. I thought it was more robust than it appeared to be, and I didn't want to spend more time to complete it, only to run into more issues. It needs some re-design.

The Bench Power Supply (Powerbug 6000), in its
open casket, the mothballs are in my head.... and my heart.

So as a wrap up, I'm just going to post some pictures I (and my wife, player with an in-law's camera) took of the project.

Seeeduino Stalker Waterproof Solar kit review

I had a little extra scratch recently, so I decided to geek out on some new toys without  a specific purpose in mind. One of the nuggets I picked up was the Seeeduino Stalker waterproof solar kit. From Seeed Studios in Shenzhen, China.

At the time of writing the kits go for $59.50 US, which, as you'll see in minute, is a pretty good deal, for what you get. I live in North Carolina, and the free shipping via Hong Kong post/registered airmail took about two weeks, give or take a day or two. As an aside, it boggles my mind that I can get something shipped out of Shenzhen *for free*, (my package was several pounds too), and I order something that ships out of a neighboring state and get socked with a $10 shipping fee.

I'm going to take a stab at doing a proper review for the kit, maybe it will inspire me to figure out what to actually do with the thing.

Slowly I turned...

It's been a slow summer. I'm still making progress on the bench power supply. It's in the "just get it done so I can move on" phase.

I've got the regulator part of the circuit finalized. I don't think it's perfect, but I think if I ever want to work on something else, I need to move ahead. Since the powersupply has three channels, I plan to have 3 discrete boards.

Here is one of the boards, pre-soldering:

One channel regulator board.

On the left side of the board, there are two PWM'ed input for the voltage and current settings, and two "Vsense" and "Isense" analog outputs that will run directly to ADC inputs on the Atmega 644. The top of the board will have inputs from the ATX power supply at 12 and 5 volts. A variable 0-9V output will come form the bottom-right side.

Bench Power Supply - Progress Update

Here's a little video I shot of my power supply in action. I think it is very close to being workable. I have a bunch of placeholder parts, since I'm holding off on placing an order for final parts until I do more testing.

One thing I've been working on recently is the current-limit-mode indicator LED's. It's a little but harder of a problem than I thought it would be. My current limit comes from Q1 in the schematic. As the current flowing through R1 rises, it causes the voltage on the "+" input of the U2 op-amp to eventually exceed the ISET voltage. This drives U2's output high which in effect ties U4's output close to ground. My idea was to connect the "+" side of U4 to a spare input on my IO expander, and sample it's value in code. My initial thoughts were that a low value indicates that the circuit is in "current limit" mode. It turns out there are numerous reasons that this wont work. The face palm moment was realizing a low VSET value will also trigger the current limit logic regardless of the actual current! The other major problem was that I was using a digital input to estimate what is really an analog voltage.

Anyways here's the video: