dajt

OK so the 2nd method is what we are using - +18v on one rail and ground on the other, swapping them using the direction signal to the motor driver. Neither of those first two sound like how I interpreted the DCC spec! Lucky some good person solved the problem for me eventually

I just realised I am still confused. If I feed the motor driver 15v, it will set one rail at +15v and the other at ground, so a total of 15v difference. But doesn't DCC want the rails set at +15/-15v relative to ground for a total of 30v difference? This is the problem I have with DCC... I just don't get the voltages.

That looks awesome I'm not going to be able to resist playing with it. One thing I can't get my head around with DCC is how the polarity swings between the rails, and how to work with this from a digital world like the Arduino. Is that of what the motor driver chip is for? It is an easy way to both supply a higher voltage and current, plus swing the polarity just using +5/0 volt signals from the Arduino?

Agreed tender, having a lathe (and milling machine if you can stretch to that) is great. Ozzy, both my machines came with guards, but I took them off too. I did start wearing safety glasses though as I have nearly been hit in the eye a few times. I broke an end mill not long ago too and the bit which flew off hit me in the chest, which was fine, but reinforced the idea that maybe I should be a bit careful. But back to that picture with the odd fitting on the cross slide, I still can't see it being for the safety guard as it just doesn't seem to put it in a useful place. The other clue would be if the machine will start with nothing in that fitting, then it isn't for the chuck guard. Sticking a DTI in there was an interesting idea.

Hi all, Two comments. 1. That 'chuck guard' looks useless in the pictured position. Most of the chips flying off the work will be zinging straight over it. It would travel with the tool which is a limitation of the one that came with my lathe which simply closed over the chuck, but still... what's the point? Better off without it and wear safety glasses. Or does it protect your hand on the carriage wheel? I do get sick of hot chips falling onto my hand. 2. I have the upside down parting tool holder from Eccentric Engineering, and it is brilliant. My lathe has a camlock chuck so running in reverse is fine. If you can do this, the upside down toolholder makes parting off from the front incredibly easy. For some reason none of the lathes I've seen sold out here (Aus) have T-slots in their cross slide tables so you'd need to be drilling and tapping to use rear tool posts. Regards, David.

That axle with the square bearings and center bush... Is the center bush quite loose to allow the axle to pivot up and down while the square bearings prevent fore-aft movement?

That's very impressive. I wish I could cut small parts out that neatly!

Just want to say what a great thread this is. Thanks for showing us how you go about it.

Hi, You should be able to get around the problem of x pins/lever by using shift registers. You'd use a "parallel in to serial out" IC to read the switch state, and a "serial in to parallel out" reg to drive the LEDs. Each reg has 8 input or output parallel lines. They can be chained together so a few pins can be used to read or write quite a lot of multiple lines. You can also get I/O expander ICs which give you say 16 I/O pins on a chip driven by maybe 3 or 4 lines from the MCU. Shift regs are really easy to use once you understand how to clock the data in. It took me a while to figure out that the first bit of data from a "parallel in to serial out" shift reg was ready before you pulse the clock. That's my plan, if I ever decide to make one of these. As for stopping the action I was thinking a switch known to be in error can just be ignored so the point or signal isn't changed. The LED tells you why it didn't happen. Anyway, cool to see someone working on the software. Regards, David.

I've only seen the distinction made in BASIC. My C64 had functions which returned values and I think had to fit on a single line, and subroutines which were just reusable bits of code invoked with GOSUB and exited with RETURN. No other language I've used has that distinction. A function may be declared to return a value or not, and if it is declared to return a value it must do so in all cases, and if declared to not return a value, it may never do so. So call them subroutines or functions - it doesn't matter. The only distinction anyone worries about these days is that of functions vs methods in an object oriented language (and Arduino is programmed in C++ which is one of these), and even then most developers don't care because it's usually obvious from the context in the conversation. For interest's sake, in OO languages like C++ a function is code which can be called but is not associated with any particular class, whereas a method is exactly the same as a function, but defined within a class and has an implicit pointer to the class it belongs to if it isn't a static method. Some OO languages don't have functions at all, like Java. But we still sometimes call them functions when we're thinking about other things. All of which is way more than you need to know to write cool Arduino programs as we saw with the above signal controller. Regards, David.

Hi Simon, It sounds like your design is essentially the same as mine, down to the red-LED locking indicators and interlocking variables! I was thinking of making the LED flash if the lever/switch was moved when it should be locked, and no movement of the associated servo(s). I've been considering defining the config along the lines of: lever n operates servos x,y,z locked by levers a,b,c I have to read up on interlocking to see what other things need to be taken into account. I was figuring something like a facing point lock could be implemented by just knowing the switch should be locked, so not moving the servo(s) when it is thrown. Having the ability to associated multiple servos to a switch is probably useful in a number of cases. Simply moving two sets of point switches can probably be done with one servo and a mechanical linkage, but there are bound to be other cases (both sides of a loop?) where things are far apart. Mechanical interlocking would be cooler, but quite a lot of work. It would also be nice to have electrically lockable switches but the only ones I found were big, expensive industrial things. Perhaps little solenoids could shoot locking bars in and out of the ends of the levers? Regards, David.

A very impressive start

Those new rods look the business. I'd love to see a step-by-step photo-journal of how you machine them... Regards, David.

Good job on the smokebox saddle, that looks like a tricky part to make with those small side curves requiring forming! Seeing that might come in handy later.

Hi Derek, I just had a look via the link kindly posted by someone else. Beautiful work. I had seen it a few years ago because I remember the part about the OO gauge track for your son, I thought that was great given most people who could model like you probably wouldn't countenance doing that Those P4/S7 types take it a bit too seriously sometimes.

MrKirtley I'd love to see more of the layout and the things running on it!

I now have a 6v battery, but am still waiting for the 6v motor/gearbox to arrive. I expected it last week, but it's on the slow boat. Going 6v means I don't need a voltage regulator - I can feed 6v to my wireless/MC board as it has a regulator built in. It also outputs regulated 3.3v which I can use for the logic power on the motor controller. I have a 7mm scale 0-6-0 chassis fairly free running now for a test but that loco is a bit too small to hide the hobby-form electronics I'm using. I have another 0-6-0 (whose chassis is a mess) which is slightly bigger but that makes all the difference - the battery would fit in one side tank, the electronics in the other, with the motor between them.

Battery powered? I want power through the air!

I took a cheap R/C car apart the other day to see what made it tick. It wasn't very useful. The R/C chip was pretty small and in DIP format, so easy to experiment with, but that's where the good news ended. It is a chip made specifically for R/C cars and is basically a set of 5 on/off switches - one each for forward, backward, left, right, and "turbo", and needs a bunch of external circuitry to work. The TX side of the pair would still need to be driven by a computer and needs circuitry too so not much saving there. Not much use for our purposes. I think these ready-made microcontroller-SystemOnAChip-R/F chips are the way to go. I've ordered another Wixel, this time without the header pins in it, along with a 6v battery made from 1/3-sized AAA batteries. I'm hoping I can make a slightly more compact R/F receiver without the header pins on the prototyping boards, and the 6v battery should be smaller than the 9v I have now. I have cheap 6v 120rpm gearhead motor on its way and some cheap bevel gears ready to use. The bore on the bevel gears isn't exactly central... they're pretty nasty. I'm going to have to learn to cut my own. Regards, David.

Some confusion while posting due to site freeze, back button, Post button, etc. I didn't mean to quote you.

I can think of at least three reasons: 1. If we just kept to the early solutions we'd all be driving Model-T fords and riding in parliamentary carriages. 2. It's a hobby and some people like to experiment with these things, just as some people like scratchbuilding or kitbuilding even though a RTR model is available. 3. Someone thinks the existing solutions aren't what they want and think they can do better.

The R/C technology is no problem, there is an 8mm sq IC which is a complete computer on a single chip including RF transciever and USB (and more). Batteries could stand to be smaller. The possibilities are only limited by the imagination, not the hardware or software. It took me literally a weekend to put together a prototype using hobbyist components and perhaps 200 lines of code to drive a v12 motor in a loco controlled by software on a PC via RF. It really isn't difficult. Sure the UI is nothing to write home about but implementing a gateway which understands the iThrottle protocol doesn't look like rocket science. The big problem I see is competing systems using different protocols between the controller and loco modules, so investment in those that don't make it is, if not wasted, not useful after a standard is arrived at, at which point you have to stick with what you have which might be out of production, or re-invest in the standard system. This is a disincentive for manufacturers and customers. At least some people are giving it a go. I am staggered anyone thinks power through the rails is a good idea these days, but it's going to cost a lot of people a lot of money to make it change. DCC took off eventually, I'm sure this will too. I think DCC decoders are an excellent choice for a gateway system, where the RF module drives the DCC decoder. This limits the RF module software to sending and receiving RF info and translating to DCC commands, which must be easier than replicating all the existing, debugged, paid for DCC features. Regards, David.

My last message has been bugging me for a while - I didn't mean to imply your NG work is "less twee" than the treacle mines, I meant it isn't twee at all. It's quite convincing.

I like your narrow gauge stuff, it isn't as twee as a lot of NG stuff seems to be. It's all looking very good.

Very nice. Quick too - you get a loco body done in the time it takes me to do some axleboxes!