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!
I have blagged some hardwood from someone rebuilding their kitchen, and am going to make some proper blanks and dremel them down. Not in any way over-thinking this.
I picked up one of these in the trove at Makespace, thinking it was a cheap board, and it turns out to be a nifty bit of kit I can use for testing. If it were both expensive and useless to me, I’d return it, but I have plans for it in testing Itchy. I’d like to be able to see a slowed-down schem of the Gcode, f’rex. Outputting directly from my computer to an external board is a goal, and this is a step along the way.
Making it work on Arch was not a problem. Making it work as described on Arch was pretty horrible. In fact, I failed at just about every point.
The only available package is moribund, which at least means I don’t have to keep it updated. Make Install was not my friend but I stripped out the default install path and put in the correct one, then kicked a few things around. I wish I could remember what.
Then I entirely failed to make udev play happily. USB Device. Udev. I have a USB device. Is it devicing? Is it hell. I don’t know if it is because I run k8055 and that tries to take the device – Arch does not have the usual installation paths for everything, so there could be something seriously funky going on. I think it’s just malconfigured, though. I am just as likely to have fucked up small as big.
It had the same error message when I had the wrong group name as when I detypoed, so something is finding the rules and failing to pass them. Currently I can work with sudo or sticky bit. Neither is ideal.
My Pimoroni Flotilla kit arrived today, and I didn’t have a Raspberry Pi left in workable condition. So, I looked for a set-up that would allow me not to use one. I found a write-up on using Ubuntu and that was hugely useful.
I already had git, so I hit
git clone https://github.com/pimoroni/Flotilla-Daemon-VS.git
in my build area. The daemon is the non-GUI backing that does the hard work of talking to the USB device. It comes without all the dependencies, though. The first one, mentioned in the Ubuntu guide, is
libserial. That’s in the AUR. I already had
libtool. As it happened, I didn’t need to make
libserial. This is fortunate, as I found out before I looked in the AUR that
pushd was not going to play nicely and I had no idea what that meant.
I also needed
libserialport-git from the AUR and
websocketpp from the standard repository. I found this out when the makefile borked, and each time there wasn’t a required dependency, I just found it. More than that, I needed to take out the version number in the Makefile.
CC = g++-4.9 is probably not allowed because it’s not pure GCC. So, I replaced it with
CC = g++ and that worked fine. I swapped OBJECT and LDFLAGS as per the Ubuntu instructions, although I don’t know if that made a difference.
Then I downloaded Rockpool, the interface.
git clone https://github.com/pimoroni/flotilla-offline
That should have run nicely with
cd flotilla-offline/rockpool && python rockpool.py but as it happens I have python3 so I made it explicit:
python2 rockpool.py and then I was done. Remember to click on Connect rather than waiting politely for the bar to load. You’re acting as a server on the USB connection, so although the address looks like the default, it is and it should be.
The rubber had perished on the sides of my pocket knife, so I cleaned it out. The original rubber came out with just a fingernail embedded in it, and the same fingernail served to clean out most of the glue. I cut leather to size with a scalpel and glued it in, smooth side down. Then I shaved off everything that stood up. It’s matted down a bit, which is not hugely pleasant to look at, but it’s comfy to hold, and I think it’ll wear to my hand eventually. If not, I can always rip it out and start again.