I burned out another Arduino, I think. I was trying to find out what was wrong with my limit switches. I’m going to swap one more in, but I’ve also ordered a RAMPS board so I have an entire solution to just put into place.
Current internal monologue: FFFFFUUUUUUCCCCCCKKKKKK!!!!!
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.
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.
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.
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.
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.
So, I have an arduino breadboarded to a stepper driver right now, and I’m staring at it, and thinking about how to control several of them. If I want tiny steps, I need to be able to switch different pins on and off, and I’m going to want tiny steps. That uses up a lot of pins.
I have two possible options. The hardware one is to have all of the driver speed pins run from one analogue pin, which I then run through a couple of comparators to get the level I want. That’ll give me output from one pin, but I do have to write out some logic tables and make the board more complicated.
The software method is to have three arduinos, slaved to a master computer (probably a Raspberry Pi by serial interface to the Pi GPio) and send the full movement to each, but screen it so that each Arduino only moves for its own movements, and hence can’t get out of step. (It could miss steps and not recover them, but that’s an issue to deal with in software, and I have ideas anyhow.)
The slot-in solution is probably a Reprap RAMPS controller, so I should look into that, but it’s extra money and a Pro Mini costs under a fiver, plus I have a couple hanging around.
I could /just/ manage a two-axis machine where I operate the z axis by hand and call the machine a plotter. That’s not likely to satisfy me, though. So, it’s time to talk with the programmer I’ve roped in – she’s going to know more than me about timings, multiple threads, and the like. She thinks I know what I’m doing. Don’t tell her!