Sparky – the failure table

This is what I’ve been putting off for a week. It’s not even very difficult, and I don’t know why I resent the idea. Probably because I’ve been ignoring it for months. Sparky has a stepper motor driver chip with step and direction dictated by logic chips based on the position of the vertical moving part, the probe.

The probe is either a cathode or an anode. I’ve never looked it up. I just swapped the wires when I wound up electro-plating things by accident.

The probe has a high potential and is connected to a capacitor so the spark jumps from the probe to the metal thing I’m trying to cut. That ablates a bit from both, ideally. We do it under deionised water so there’s a lot of resistance around the spark and it stays very precise. It also doesn’t short out through the water. So, if the potential is and remains high, we know it’s not near to contact.

If the potential’s low, we know it’s grounded (physically, and therefore electronically). It’s touching the metal thing we want to cut, and that’s not good.

If the potential’s jumping around madly, we know it’s sparking, and that’s where we want to be. So, we need to keep track of the level of the spark probe, and decide from that what the Direction wire should be doing.

A circuit diagram showing a circuit built in several parts
A slightly scribbled on circuit diagram

So, we have /U (pronounced U-bar, and ideally written as a U with a bar on top of it) and /D. Those mean NOT U and NOT D. We directly wire /U to DIR, the direction pin on the stepper motor. /D is used with /U in a calculation of whether to fire off the stepper at all. The ‘down’ and ‘up’ here are arbitrary, because we have two pairs of wires we can define as up or down, and we just wire them to the stepper.

We take the level coming off the spark circuit, and run it through two comparators. /D is high if level is greater than the limit we set, a bit under 5V. /U is high if LVL (the level) is lower than the limit we set, a bit over 0V. That means we can easily have a situation where the level is between the two. At that point, /U and /D are low. If the comparator chip disconnected, we will get a situation where the later 5v 10K pull-ups will make both lines high.

So, the ideal behaviour if we turn the machine on and something electronic is broken is that it will move upwards. Our default move is ‘up’. Or we can hit the /U line and say ‘not up’. The name we apply to our line, and whether it’s high or not, doesn’t matter. I’ve wired them up in orange and green, to be able to look at them. So the ‘orange’ line is high when we want to over-ride the default behaviour of going up, and send the probe down instead. If we mounted the motor sideways, the orange line would be sending the probe left and right instead.

So, without further ado, the input/results:

 /U | /D | gate | DIR | result | Explanation
---------------------------------------------------
  0 |  0 |   1  |  0  |    U   | NOT NOT UP. Up.
  0 |  1 |   1  |  0  |    U   | NOT NOT UP. Up.
  1 |  0 |   1  |  1  |    D   | NOT UP. Down.
  1 |  1 |   0  |  1  |    N   | NOT UP. NOT DOWN. Gate stops.

An extra good point here is that if /U is low, it will consistently go up no matter what /D’s state. That means we can use a cut-out to force the motor to move even if the microswitches are bottomed out. I need to expand that when I write this out properly. At Project End I’ll do a full breakdown of the circuit board.

If I can output that as a small LED array, I should be able to see if something’s going wrong. Expand the testing and put it to a serial monitor with the Arduino, and I’ll be able to tell why it’s going wrong too. So, now that’s written down I can get back to staring at Sparky in sure and certain hope.

Sparky – or, How To Shave A Yak

So, the reason I have this blog is to keep a record of my non-painting projects, most of which are in a constant state of tinkerage. The big one is Sparky. Sparky is my finest piece of yak shaving to date.

Yak shaving, for those who don’t know, is the end result of a linked set of tasks which lead back causally to the original task that started it. See rationalwiki.org/wiki/Fun:Yak_shaving for the full definition and some very fine examples.

I don’t know what the original task was that made me start on this course, but here’s the part of it I remember….

... I need to learn how to use the Mill in makespace
but there isn't a course so I'll co-write a course.
...now I have a broken centre drill in my practice piece
BUT Mat says spark erosion's pretty easy.  We'll build a Spark Erosion machine to get it out
Now I need to write an Arduino program, to read off the data from the electronic board.
What could possibly go wrong?

So far, I’ve spent about a year and forgotten my original task. It was probably something to do with art, but it’s turning into a machine that includes research on yak species as version names.

Learn C the Hard Way – big numbers

Yep.

If you take a number that has an optional sign, you need to leave room for the negative numbers. If you don’t, all that room can be added up top instead, effectively doubling the size of the number-holder you can play with, as long as it’s positive. If all you’re concerned with is the size of the number, that’s cool. You’ve got a box that’s twice as long, but each unit in the box is double the size of the one before, so an unsigned long is really MASSIVE.

It came out as 0 on my output. I don’t know why. Um, maybe the computer itself couldn’t handle it? Compiler was happy, valgrind was happy, but it was outputting as 0. I’ll have a think.

Extra credit asks about why chars and ints can be treated just about the same. Well, it’s just ones and zeros, innit? So if the char and the int can be interchanged, then they get to be. If not, if one won’t fit into the other, just throw a wobbly in the compiler.

Learn C the Hard Way – chars and strings and tigers and bears

‘Kay. So now we’re looking at the char[] without a *. So I’m going to guess that the * means multiple argvs of type char[] are available. Still keeping that on the back burner.

I’m getting closer to a problem I have on the Arduino, where I want to output in a particular format, binary with 0 padding at the front. That’s %05d – but I don’t know how to pass the right thing out yet. Maybe printing it as soon as I calculate it and not trying to pass it back out for the printing later on. Now I know what printf can do, I’m happier trying that, although I believe I need sprintf – stringprint. Again, not a thing to look at yet.

Breaking things for extra credit:

char x = ”; is an error. Char is explicitly 1 character long. Related to the ” instead of “” I figger.

char x[] = “” isn’t an error. It’s 0 length but that doesn’t really matter. It’s initialised as a space for there to be a string, and that’s that.

printf("")

– sort of funny. How can you tell if it’s done anything? I’m assuming it exists because the compiled program has some size, and I left it on its own in there, but it’s a 0-length string. The compiler doesn’t like it, but goes for it anyhow, but when you run it nothing appears to happen.

By law I must now link to Oglaf’s Fountain of Doubt. (SFW)

Subtle, isn’t it?

Putting an int into a char results in the character returned being (I guess) ASCII result for that integer value. So that’s not broken, but it’s potentially unexpected. That’s how I got H out for integer 72 in an earlier exercise.

According to www.cdf.toronto.edu/~ajr/209/notes/printf.html s is already a char pointer. I think that’s just a sign that says ‘use this long thing over here’ instead of having to write out what the long thing is in a compressed space.

Learn C the Hard Way – Lucky I already thought of that

Because I was remapping the keyboard, I left my terminal in root, and ended up creating an exercise as root. So later, I couldn’t amend it. Options were chown, chmod, or just leaving it there and not caring. Fortunately, I already had exercise expansions and extra credit as different files, so it didn’t affect me. However, pro-tip here; don’t do that.

Learn C the Hard Way – packing away my ego

Ex 5. I’m pretty good at copying typing I can see, but unfortunately I’m also pretty good at remembering what I’ve seen in previous exercises, so I nearly made the argvs into ints. Brain managed to pull up at the last minute, though. However, that’s one to be very careful of in future.

Line 4, /this/ version of the main function needs that combo of ints and chars. I took a moment realising that that was not a universal truism for main().

Line 5, starting the body of the function, threw me for a loop. I’m learning this because I’m messing with an Arduino for my current project, Sparky. That means I’ve been basically copying and pasting and trying to make things work. So I’ve seen an if() that had brace pairs and an if() that didn’t. For a moment I was trying to over-ride what Zed says. Obviously here, the {} are only required if there’s more than one line…

So I’m going to believe him. That’s a very hard thing for me. And yeah, a bit later on we’re told that statements end in ; – except logic.

What’s going on in there is that we demand an int be returned, and then we return a 0 at the end, and in between we do all sorts of interesting stuff. I believe we could type

void main(int whatever)

if we wanted to input ‘whatever’ and get nothing out. We’d just do stuff inside the main function. That’s how the Arduino sets things up. It has void loop() and that loop just goes round and round and round, doing stuff but never actually outputting.

I think the only thing I’m unsure of is the char *argv[]. The [] means it’s an array. (I know that because I’m working out failure messages for Sparky, and that’s how they are filed.) But char* x is different to char *x and the * is worrying me. Pointer. It’s a pointer of some sort. But is *char a pointer to a character… well, colour me ignorant. I’m guessing, not looking this up. It’ll end up explained.

Learn C the Hard Way – Arch is a bastard for this and I’m fine with that

Ex 4.

Valgrind is available in the /extra repository in Arch. We’re going to make it ourselves, though. Fair enough. I’ve made a few packages as far as I recall, but not in a while. When I was initially setting up my machine, inkscape wasn’t so good and I was using inkscape-bzr and now I don’t need that any more.

$ tar -xf <FILE>

is enough to unpack most things. ‘eXtract File’. The tool will work out what sort of file it’s working on and just does it.

$ ./configure

– error. Valgrind works on kernels 2.4 and 2.6 – Arch is a rolling release. I’m on kernel 4.something. Soooo. Package manager it is. At some point I’ll need to work out what about the package has been changed to make it work in Arch. The README.aarch has instructions on cross-compiling and paths and hosts which have a shape that makes sense but I’m not looking at the detail. I’ve used pacman and I have valgrind on the system. I stared at the Makefiles that my attempt generated, though, in the hope of absorbing their strength by drooling. On with the lesson.

The output of valgrind is already similar to Zed’s, but at some point I may diverge – Arch is like that. For now, though, I’m getting error tracking.

By fixing the uninitialised variable in ex 4, I fix all the actual errors. This is odd, as valgrind doesn’t pick up the %d without a related integer, in the first printf function. I can’t see why that might be in the manual. However, I know what the program should say, so I know what to fix. An uninitialised variable is an error that could lead to unexpected problems, and valgrind picks it up. A variable that’s missing could lead to, well, also unexpected problems. But valgrind doesn’t pick it up. Odd. Maybe an Arch thing but I don’t think so. It was not there in Zed’s print-out either.

The compiler tells me what the other problem is, so I’ll deal with that. Variables are now initialised and don’t go unused, and all format sequences are filled.

I did some messing about with making downloaded packages, but I’ve got to look into Arch’s installation process to really understand that. pacman is a powerful tool, and like all powerful tools, it hates me right from the off. I know I can make a package and then have pacman install it from my local file, but for now I’m not using that. Onward, upward, and avoid the Pevensey children on the way.

Adventures in Keyboard Mapping

I have a laptop which was very kindly donated by a friend. It’s better than any of my other computers, which isn’t hard. However, it’s a US layout.

I’m currently using a VM to learn C, as I like Arch, but I’m doing that inside a windows interface, for which I’ve had to remap my keyboard. So, inside that VM I have Xwindows and consoles, and they all need mapping.

Well… I can copy and paste #~/?| and all those things. I don’t need them. As long as I have £. And ¬.¬ of course.

I don’t like emoticons.

Fuck.

Learn C the Hard Way – placeholders, thingies, format strings, and my brain holding too much

Ex 3:

Easy enough. I had to look up exactly what a format string was, but that’s fine. Zed flagged it up for looking. This is quite a lot like Python’s %s and %d functionality. Just different syntax.

So, trying to break the printfile, I found that

printf("%c", height);

would look up height (an int that gave numeric value) and find it was 72. So it would then look up the character 72 in ASCII, and return an upper case H. That’s the DEC version, by default.

Unicode gives me a WTF character. I assume I need a different library to deal with that.

A missing age variable gives me a ludicrous age, but doesn’t crash the program. I can embed the width of the returned number or string in the %symbol by using %+4i – width of 4 digits, including a sign that will always be shown or %10.3f – that would give a minimum width of 10 digits including a decimal point, and 3 figures after the point. A – will left justify shit. I’ve been told that C is really concise, and that’s a good example of using not very many characters to type stuff. It’s not exactly confusing form with function – the format characters sit over the stringy bits. They just sit over it inside the same bit of typing.

r is a return to the start of the line without a new line. I can overwrite the earlier part of a string with it.

So, I’ve got various ways of breaking printf(), but those are mostly bad typing. I can also accidentally cover over a result, or leave big spaces in a result.

The last bit of the Extra Credit wouldn’t be clear if I hadn’t done a bit of research already. The ‘list’ of the makefile isn’t, I think, a thing Zed’s defined. In Ex 2 I cleaned up a bit when I took out ex1 as a dependency for all:. Now, I’m going to make it so ‘clean’ and ‘all’ have the lists I want inside them. For the moment I’m typing out all the names, but I’m aware there’s a way I can substitute in everything that’s in a folder, and stuff like that. I don’t mind having had to look up what the list and the dependencies were – Zed’s trying to make new programmers thing for themselves. I am concerned I’ll be trying to look up too much, which is a problem I always have. Knowing when to stop is a skill you don’t pick up until you know what’s important, and you don’t know what’s important until you’ve practiced for a while. So, every time my brain seems too full, I’ve probably gone too far.

www.le.ac.uk/users/rjm1/cotter/page_31.htm has a good list of width/precision stuff, but the examples are odd.

printf("%s,Hello")

– I’ve eMailed the owner there to ask how the heck* that works. It breaks my program by printing out the last parts of my previous lines. It compiles (badly) and then it betrays me. Le whut?

* I used different words.

Go to L – milling experience

A cog with a slit and an L-shaped piece that fits the slotWhile waiting for client feedback, I came across a couple of people (F. and J.) who were picking apart a broken mechanism, but couldn’t find an easy way to fix it. It had some 3D printed parts, and the ABS had twisted apart, and was jammed inside because it had a flared end. So, I milled down some plate steel while J. drilled out the broken plastic and worked out how to keep a spring out of the way, then we fitted the steel key. In place of the flared end we put in a notch and wired the steel into position. The top needed a star shaped meshing mechanism, so I cut that out of plywood on the laser cutter.

The steel cut pretty easily, but I had to be careful with the vice, as it was thin and I got to the point where I couldn’t safely hold it, and we were very lucky that was a perfect fit for the mechanism. I could take off a 1mm step with the 16mm end mill, and I did that repeatedly, with lube, and it works just fine.

We need more molyslip.