Jump to content

RobjUK

Members
  • Content Count

    265
  • Joined

  • Last visited

Community Reputation

216 Good

Profile Information

  • Location
    : Sheffield, England
  • Interests
    Computers, programming, music, renovating guitars, model engineering.

Recent Profile Visitors

300 profile views
  1. I'd say it is inherent with the airbrush design? When you use it, paint is pulled up out the container to the nozzle. The pick-up pipe then stays full of paint when you release the trigger. Take the container off and you open the bottom of the full pickup pipe - allowing air back in and the paint out. Letting air in via the trigger first, allows the pickup to drain back before the bottom end is opened up.
  2. That airbrush looks very similar to one I have; press the button/lever for air control & pull for paint flow? If so, try pulling the level full back without pressing for airflow, so air can get back into the paint channel through the nozzle and allow the pickup tube to drain back?
  3. A dead winding or dry joint on the commutator motor could cause something like that - or just a very dirty commutator or contaminated brushes.
  4. How about a "one coat" plaster? They are fine particle but OK in thick / solid sections. I've never tried one for casting, but I have used the stuff in the past as bulk filler and it works well. You can get it from such as wickes or B&Q, or in 25Kg bags (around £15) from builders merchants. https://www.diy.com/departments/thistle-one-coat-plaster-12-5kg/147437_BQ.prd https://www.wickes.co.uk/British-Gypsum-Thistle-One-Coat-Plaster---12-5kg/p/141937
  5. Videos - I've only got the sound working for startup and idling so far, nothing while it is moving, so two separate clips for sound and motion: (The driver is on loan from the Barclay project)
  6. I still have a lot of tidying up and finishing off to do, plus the centre engine cover to make. The sound project also needs a lot! of work - I have a new respect for the people that do them full time! It runs, but so far the control is very touchy at low speed, which I think is due to it being a nominally 3V motor. Hopefully it will improve with some tuning of the motor parameters.
  7. I never realised how strong loctite could be on something as small as this, I ended up prying the shaft and sleeve in opposite directions with two pairs of sidecutters & still needed to heat the shaft with a soldering iron to try and break down the locktite. The gearbox shaft was wrecked in the process but luckily one of the DAS87 shafts was exactly the same size. I took the gearbox apart and soldered the output gear to the new shaft, to try and be sure it could not come loose again. The minor disaster turned out to be a benefit in a way, as I could offset the shaft and move the gearbox near one side. I also left out the inner bearings when reassembling it - with the joints as strong as they were, it had no need of any extra support! With it now turning the wheels, I added the decoder (ESU Loksound 5 micro) and some pickups. The result below:
  8. The cast front and footplates / mudguards are from a Wiseman static white metal kit, which is a slightly smaller scale, hence the split and stretched footplates. The seats are spares from some other 7mm parts I collected for my other projects. Painting was rather slow - I tries airbrushing the yellow to start with, but all it did was put a faint tint over the primer, It ended up with something like five coats by brush to get a solid colour. The drive system all assembled quite nicely, or so I thought - the machined 2mm to 1.5mm reducer bushes pressed in to the wheels, with a solid 1.5mm shaft at the back and some DAS87 1.5mm OD sleeves in the driven wheels, through the bearings. Everything test fitted, then reassembled with locktite to permanently fix it. After it had time to cure, I tried the motor and that ran nicely - but the wheels did not turn! The gearbox shaft just turned freely with no connection to the motor. At that it went back in storage for a couple of weeks.
  9. Some of you may remember I was enquiring about possible sources of very small wheel for an O Gauge / 7mm project last September. Based on PatB's suggestion, I got some Marklin HO wheels and started trying to work to what to do with them... When the wheel sets arrived, I found they had 2mm axles. The only tiny geared motor I could find had 1mm axles & far too narrow. More parts searching followed, ending up with a mix of DAS87 spare shafts & sleeves, some Nigel Lawson machined adapter bushes, 1.5mm bore bearings and other various bits of shafts. Then brass "chassis bashing" - The photos show the progression, spread over several months as time and parts sourcing progressed:
  10. I've just found an advert for Peco point motors that gives the current requirements - Two amps. 7/02 wire has a resistance of 93 milliohms per metre, almost a tenth of an ohm. Double that when calculating for a two-wire loop; call it 0.2 Ohms in round figures. Based on that, each metre of the loop from source to destination would lose almost 0.4V at 2A With four point motors in parallel, that become 1.6V per metre lost. Personally, I'd not use 7/02 for any power handling circuit of more than a few inches and at low current; I'd suggest something quite a bit bigger for the points, possible even 1mm^2 flex for the multi-motor cable run.
  11. Probably not directly relevant to your existing problem, but to prevent future ones: It's not a good idea to tin wires that will be used in screw terminals of any type. Solder is relatively soft and will flow over time, allowing the joint to become loose. That's professionally been considered bad practice since the 60s and it is a specific item in electrical safety regulations as with power circuits, a loose connection over time can cause overheating or start a fire. The regs do not apply to low voltage hobby wiring, but the reliability principles do. Another downside is that you get a stress point at the end of the tinned area and the individual strands are more likely to fail there over time with movement or vibration. A detailed explanation here: https://cdn.thomasnet.com/ccp/00142951/263810.pdf If you want to prevent the possibility of stray wire strands, the preferred was is to use wiring ferrules, aka Bootlace ferrules. They both hold the strands and act as a strain relief, giving some support to the wire insulation. Hopefully this may save another faultfinding session in a few years time!
  12. You can get various mixed packs of Vallejo acrylics for different purposes; whether they would be suitable depends on the colours you need? (I've never built anything like the items you mention.) I have an assortment of those plus various "Railmatch" acrylics and enamels for different things, they seem to work well. If anything you are building involves any non-ferrous metals, you will need some suitable primer as well. I've found the Hammerite "special metals" primer that Halfords sell to be exceptionally good for that, it's easy to use, water based but bonds in like it's become part of the metal.
  13. Not in the slightest - but I have a deep dislike of people trying to use buzzwords and empty claims to sell things or extract money from non-technical people. Your "advertising approach" is such broad claims ,with no technical info about _how_ it supposedly does everything you claim - and a load of factually wrong or misleading comparisons. I apologise for the github comment, there is a single program code file; the description made it appear at first sight to be another text document. However looking through that, the track control is nothing but open-loop PWM; no current sensing, no back EMF sensing. It still does not back up your claims of superior control. If the device code you show in the video is supposed to be internal to the system, what is the point of the monstrously complex "API" - you only actually need to set and retrieve a very few parameters from each power controller channel and the entire set could always be in a single tiny data block, just a few bytes each each way, with just one form of interaction. Having the massive "API" with many different functions passing a single parameter each seems incredibly wasteful, when a single call could pass an entire structure each way all in one go. That would also need a lot less WiFi channel occupancy. The difference is trying to measure motor feedback at the motor, or remotely through an variable connection. And you cannot properly measure motor current or back emf for precise control if there is another load (such as lighting) across the motor - it's the lighting (in your concept) that would affect motor control, not the other way around. The ESP32 is only available with 2.4GHz WiFi as far as I can find, so other bands are irrelevant. And, you have just proved your total ignorance of WiFi operation - the channel numbers are a leftover from earlier systems and a single actual WiFi transmission requires the bandwidth of multiple numbered channels - either four or eight. With proper planning a maximum of three systems can coexist, using 20MHz bandwidth. If anything uses 40MHz, it effectively takes over the entire band This is an example of channel usage - but remember you only have 1-11 in the USA, not 1-13 as in Europe.. https://i.stack.imgur.com/CG9d8.png Which is enough to prove that source code examples for various DCC implementations exist & it's not a totally "closed source" system as you claim - I've got better things to do than trawl google. And any decent programmer can knock up a DCC decoder program in a few hours; that's the point of the open standards and publishing all the signal waveforms and timing requirements, so anyone can create compatible equipment for themselves. I've written two decoder routines on two very different devices, just for the fun of it - one on an 8 pin PIC and another on a DSP chip. I've not used them for anything so far & I may never do, it's purely technical interest and to see how efficient I can make the code. But still only one loco per block, so you cannot have locos continuously in close proximity, or simply connect a controller to a layout and run as many things on it as you wish. Overall, if you have some original and technologically good ideas for power/speed control to locos, good for you - go with it. But so far, the actual "power control" system that feeds the track is nothing more than open-loop PWM that can be done any number of ways with off the shelf parts - there is no precise speed control or load sensing, and trying to do such things from a track power controller can never possibly give as good a result as having the speed controller at the motor. The signalling method is a totally separate issue, and irrelevant if the motor cannot be properly made to respond as commanded. I get the impression you have never actually examined the full details of how a DCC decoder (or any closed-loop motor controller?) works and interacts with the motor, or you would not have made the invalid claims of superiority of your system. [Designing, programming, manufacturing and repairing industrial control systems ranging from radio links and embedded controllers through to heavy industrial drives, robotics and machine tool power and control systems, for many years. Plus electronics, programming & radio design (licenced ham operator since 1979) as hobby interests].
  14. Exactly! If you control the track power, you have all the drawbacks of track-wheel connectivity. If your lighting module is not controlling the motor, then that's also messing up any armature feedback through the track DCC puts the motor controller in the ultimate location, directly against the motor. With buffering, which many newer decoders include and is a simple add-on for most others, temporary loss of track connectivity is irrelevant. Garbage. You are comparing two totally different things in a meaningless way. The performance of whatever CPU is in a device is irrelevant, as long as it is sufficient to do the job properly. DCC is a signalling protocol that does not require radio or cause interference to other services. And using WiFi is, to be blunt, idiotic. The ESP32 is 2.4GHz only. With any system using 11n in the area, there is not sufficient bandwidth for even two simultaneous transmissions without collisions. In many cities 2.4GHz systems slow to a crawl or just give up at times due to congestion & hidden station effects. More garbage. The components used in DCC decoders are all off-the-shelf parts. Anyone can build them from various kits or by buying parts & using stripboard or whatever. And source code?? There are dozens if not hundreds of examples freely available I've just found an N-gauge decoder design, even - source code included and about $5 in parts to build: http://web.nucky.jp/dcc/decoder4/onecoindecoder4.html Or a source package on github: https://github.com/Railstars/Aegaeon And of course all the MERG stuff, which is dirt cheap, extremely well designed, and with free source code. IF that were the case, I may have been slightly more impressed by the idea - but the github repository apparently contains nothing but waffle and blurb. You can run any number of locos independently from one controller on one layout. Track power control means one loco per track section & one controller for each section. You need as many controllers as locos, and without the seamless running of DCC systems.
  15. Interesting idea, but I can't help but think some of the claims of this vs. DCC are a bit far fetched? eg. How can a track-connected controller give better speed control than a DCC decoder directly in a loco with no extraneous connections between that and the motor? And far sillier, the claimed advantages technology-wise or cost-wise of this over DCC. DCC is an open standard, not proprietary. It does not need any "special components". There are many examples of software, source code and command station / decoder hardware designs freely available. In your proposed system: You have a microprocessor controlled unit that applied PWM power to a track. You also have a microprocessor based unit that plugs in to a loco DCC socket to provide direct control rather than whole-track control. How are those two any different, other than software / firmware, from a DCC command unit and loco decoder? The parts cost cannot be different purely due to different programming requirements - in fact using non-wifi modules, as that is not needed for DCC, would be cheaper still! If you can make them at such an advantageous price for end users, why not make them DCC compatible so you have a much wider market?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.