Itchy: leaps and bounces

All of Itchy’s parts work individually, and Co-squid found a tool chain that will drive the Arduino from output from Inkscape. Inkscape has gcode extensions. Of course it has. So now, I just have to put it together. The machine went from jerky, jumpy bouncing to having some smoothness of movement today.

Co-squid goes back to her house soon, and I’m going to have to work out where to put what I am calling Itchy and she is calling Murderbot. Given the fragment of scalpel I found in the second hand parts, I think it already was a cutter. I’m going to find some way of keeping that bit of scalpel in there.

Itchy: work list

I’ve got a gantry, and some bearings; those need to be joined. The blocks need drilling, partly tapping, and to have the tender minstrations of a slitting saw applied. I’ve got a day to do that.

I need to assemble it all, including the blocks and a central lead screw. Then the gantry has to be attached to all of that. I don’t have a connector for the lead screw right now. I’ll look into oldham connectors just because I haven’t used those yet, but I’ve ordered another of the aluminium spirals. Last I looked, oldham connectors cost money. It would be fun to make one, though, so I can say I have.

The microswitches need to go onto the frame, and be wired in.

I need to 3D print cable lay, and work out where to put it, including platforms for it to run along if necessary.

My programmer squid (don’t ask) arrives tomorrow, and I need to get her up to speed. I fully expect I will then be left in her dust. I’m OK with that as long as she leaves a trail of comments.

The breadboarded electronics need to be veroboarded.

ZipPi: Project finished (ish)

Today I bought a new HDMI screen and connected everything up. I now have a working Rasbian computer with wireless mouse and keyboard. I’m well chuffed.

I’d like to do a lot more on it, like wire in the USB sockets on the top of the case, which isn’t horribly difficult. Right now, though, ZipPi is a functional, dedicated computer. It may be a Raspberry Pi 3 soon.

ZipPi Boot-up success

ZipPi the Raspberry Pi computer now has a MOSFET and board, and uses two case LEDs that indicate power to the board, and power to the Pi. It boots up, and we have played with it, but it needs a dedicated screen, mouse and keyboard, and a wireless dongle. I might get something with a decent antenna, or I might just get the Pi Dongle again. Those have to be extended out the back so I can close up the aluminium case and have it done. The board also has to be mounted inside its allotted hidden dead space. It works, though. And nothing burned down.

Itchy Gantry – proof of concept

With the help of an engineer at makespace, I debugged the gantry. Running a multimeter across the wires to check the resistance of each motor coil made sure that they were not burned out, but then we got out the oscilloscope and tried to work out why the hell the driver was not driving.

Finally we spotted that the live jumper that should have been 11V was only about 2V by the VMOT pin. We whipped that out, put in a different jumper to some different spots on the breadboard, and got the X motor working again. Then the Z driver got put in (although not attached to the lead screw) and they both worked.

I know how to build the Y axis on the unsupported rod, by clamping X section aluminium in front of and behind each of the cylindrical bearings. That’s then two points of contact along each rod, and each of those points can move, so I lock them together with more X section and bolt the gantry to that. That’s the minimal build that my programming friend will need.

I’ve got end stop microswitches, which I’d like to get into place as soon as possible, but cable lay is probably more important. Still, the gantry head moves and the motor on it turns, and that’s nearly the Morse Code machine I’m after for this stage of the build.

Also, am chuffed; the guy who was helping me probably has a spare bench power supply to lend me, so I’m going to be able to do more at home. He wrote down the name of the motor driver I was using, so as well as solving a problem with me, he got something definite out of it. DRV8825, for the record.

ZipPi Power Supply

The MOSFET I wanted to use doesn’t provide much current at 5V. I’d seen the graph but my eyes had passed over it until Mat read it off, and then I understood what it meant and why it was important. And, y’know, why I should pay attention to the fact that graph is an upward curve. More voltage means more current – and I want to run the Pi at 5V through the USB power supply. It’ll protect it best, and allows for most flexibility. .7A is not enough.

Mat gave me the right sort of MOSFET, although he did insist on breadboarding it himself. I say I’m just teaching silicon to respect me.

Learning out of this: graphs are probably important. I should look at them or something.

Itchy Motor Driver Failure

So, picoFarads are not the same as microFarads.

I was reading a data sheet on my phone and the mu looked enough like a p that I put in the wrong capacitor. I might already have burned it out before that, although I think the power supply was regulated and it should have been fine – but once I turned the power on properly and had everything at the right levels… the 11v line kept trending downwards. The motor power supply was grounding. The magic smoke had escaped.

I needed to check that I hadn’t burned out the motors, which I did by checking their resistance. At about 3 Ohms, that was not hugely high (burned out) or very low (a direct connection that should not exist inside the motor) so I hadn’t fragged the bigger hardware. Just one chip.

With the help of someone hiding from work at makespace, I worked out the problems I had left – chiefly that the power supply to the working motor chip was not seated properly, or was somehow resisting. I suspect a bit of fluff or dirt in the breadboard, but whatever it was, the gantry started doing what it should have when I pulled out the jumper and put in a different one to different holes.

Having someone who knows what to look up and why makes a huge difference. I’ve mostly done this project on my own, but today someone else’s knowledge took a couple of hours of what would have been hopeful poking and prodding, and made it efficient. (I need to grab the oscilloscope as a reflex, not after trying lots of other things.) So, I had the Z axis motor working, and the X axis motor moving from the same Arduino, and I haven’t yet built the Y axis at all. I’ve got about 3 weeks to do that.

Sparky: pumps

I wired up the second pump, which runs at a different voltage to the first pump, to Sparky, so we now have boards with voltages of 48v, 24v and 12v. I don’t think I’m going to be looking at 6.

I /think/ the 12v is 12v. I just got hit by a nagging suspicion that’s my stepdown to 24 and now I just don’t know. Balls. I mean, I know at the time that I tried to make a stepdown and then I found the board thta did it… but did I know at the time or did I just remember knowing? Doppleballs.

Itchy: step size solution

The engineer who came pre-installed at our workshop pointed out to me the way to do steppers.

The Arduino can tick over far faster than the stepper driver wants to move. (This may not in fact be true; I went for some rather over-spec stepper drivers. But arguendo, this is the case.) So, I use the smallest size of step, and crank up the tick rate. I can use the Arduino to time the steps so if I want to slow down, I’m just missing out a lot. That restores a lot of the pins I thought I was going to need, and makes me a happy person.

He also had some things to say about end stops and soft stops – he says it’s best to do it in the microcontroller, because that will keep track of the last direction in which you moved. If you try to cut out the stepper controller by over-riding the direction at the same time, you’re going to get a race condition.

Lastly he added the purely mechanical point that you can ramp the head up the cut-out switch rather than risking flattening it coming in from on top, and still have the hard stop beyond the switch so nothing falls off at high speed.

Itchy: End Stops

An end stop has two states. So, if A is triggered to make Dir explicitly head away from the stop, then /A will also have a change in state, which can be used to feed in info telling the machine there has been a hard stop. This can be used both for zeroing, and for a full ‘WTF all brakes on how did you get out of bounds’ that happens in software – but that is a slave to the directional change we apply directly to the DIR pin. It might be a toggle gate/flip-flop.

The electronics of this may need testing, but it should be possible to hit a high pin to ground and not have the direction go high. That is, to have the grounding effect be bigger than the directional instruction, If not, the software still works. Pull-up/pull-down resistors may be involved at the pin end. Need to dig out whether you can have a resistor as an out pin. Don’t think so. But as an in pin would be fine. Still, it takes an extra pin in.