Author Topic: Back to DC  (Read 15661 times)

0 Members and 1 Guest are viewing this topic.

DKS

  • The Pitt
  • Crew
  • *
  • Posts: 13424
  • Respect: +7026
Re: Back to DC
« Reply #60 on: December 11, 2017, 01:19:32 PM »
0
Assuming a loop yard always operates in the same direction (and there's no reason it shouldn't), then you'll need one detector on the inbound end, right after the first turnout, but before the turnouts for the storage tracks, and then one detector on each storage track at the other end, just before the fouling point.

As an example of the sequence of actions, assuming that the last train to depart the yard left from track 1: The inbound train trips the inbound sensor, which enables the outbound sensor on track 1. When the train reaches the outbound sensor on track 1, it a) shuts down track power; b) realigns turnouts to track 2; c) realigns the first turnout on BOTH yards; d) disables outbound sensor on track 2; e) restores track power.

All of this can be accomplshed with a microprocessor controlled circuit, or a bunch of relays. I've done it both ways, and found the latter to be more robust as it's immune to the electrical noise generated by locos, switch machines, etc. But, YMMV.

strummer

  • Crew
  • *
  • Posts: 998
  • Respect: +65
Re: Back to DC
« Reply #61 on: December 11, 2017, 11:04:10 PM »
0
This is all very fascinating. I recently posted a DC question which I put into the "Crew Lounge".

It ran there for a few days and was then moved to the "DCC/Electronics" category, which I get.

Shouldn't this topic be moved there as well?  Just wondering...  :)

Mark in Oregon

mmagliaro

  • Crew
  • *
  • Posts: 6368
  • Gender: Male
  • Respect: +1871
    • Maxcow Online
Re: Back to DC
« Reply #62 on: December 12, 2017, 11:06:45 AM »
0
This is all very fascinating. I recently posted a DC question which I put into the "Crew Lounge".

It ran there for a few days and was then moved to the "DCC/Electronics" category, which I get.

Shouldn't this topic be moved there as well?  Just wondering...  :)

Mark in Oregon
Is discussing where a topic should be a thread drift?   :D
For my $.02, since this topic is really about how to construct a reverse loop layout, I don't think it really fits the electronics forum because there is so much more to it than electronics.  There's trackwork and layout design, plus the electronics.

strummer

  • Crew
  • *
  • Posts: 998
  • Respect: +65
Re: Back to DC
« Reply #63 on: December 12, 2017, 11:35:25 AM »
0
HA!  :D

You know Max, as soon as I posted that, I kinda reached the same conclusion, although the title does imply "electronics", and nothing more.

Mark (also) in Oregon

nkalanaga

  • Crew
  • *
  • Posts: 9898
  • Respect: +1446
Re: Back to DC
« Reply #64 on: December 13, 2017, 01:39:01 AM »
0
It could go into Layout Engineering Reports, but it really isn't about an entire layout.  Too bad we don't have a forum just for track design and construction, all scales, but I doubt that it would get enough posts to be worth creating it.
N Kalanaga
Be well

Doug G.

  • Crew
  • *
  • Posts: 1099
  • Gender: Male
  • Respect: +43
Re: Back to DC
« Reply #65 on: December 13, 2017, 02:37:40 AM »
0
Since we have these loops and the Fruit Loops of the other thread, we need a  "loops" forum.

:D

Doug
Atlas First Generation Motive Power and Treble-O-Lectric. Click on the link:
www.irwinsjournal.com/a1g/a1glocos/

Sokramiketes

  • Crew
  • *
  • Posts: 4974
  • Better modeling through peer pressure...
  • Respect: +1530
    • Modutrak
Re: Back to DC
« Reply #66 on: December 13, 2017, 08:22:12 AM »
0
Assuming a loop yard always operates in the same direction (and there's no reason it shouldn't), then you'll need one detector on the inbound end, right after the first turnout, but before the turnouts for the storage tracks, and then one detector on each storage track at the other end, just before the fouling point.

As an example of the sequence of actions, assuming that the last train to depart the yard left from track 1: The inbound train trips the inbound sensor, which enables the outbound sensor on track 1. When the train reaches the outbound sensor on track 1, it a) shuts down track power; b) realigns turnouts to track 2; c) realigns the first turnout on BOTH yards; d) disables outbound sensor on track 2; e) restores track power.

All of this can be accomplshed with a microprocessor controlled circuit, or a bunch of relays. I've done it both ways, and found the latter to be more robust as it's immune to the electrical noise generated by locos, switch machines, etc. But, YMMV.

I think I'm good on the logic and the sequence, what has me tripped up is an easy way to speed up and slow down without simply going to an on/off triggered lurching.  And just thinking through a capacitor set up, led me to the thought that it would be dependent on how many locomotives on the train... which just triggered a thought about how do I speed control this whole thing. Each train will have different speed needs, or else some diode bridge on two-motor sets to match 3 motor sets... Maybe I need a throttle for each train? Now I'm back to the SECSI computer control components instead of an elegant hardwired solution. 

I understand why the path continually leads to DCC for these issues. 


DKS

  • The Pitt
  • Crew
  • *
  • Posts: 13424
  • Respect: +7026
Re: Back to DC
« Reply #67 on: December 13, 2017, 09:43:02 AM »
0
I understand why the path continually leads to DCC for these issues.

I understand why many people would belive the path continually leads to DCC. But I never have.

I've considered capacitors as an answer to this for some time as well. But I believe it can be solved much more effectively by controlling a PWM throttle with a microprocessor. (Before microprocessors were prevalent, I built a throttle that was controlled with a geared motor.)

Having said all of that, what is your concern about speed control? Do you want the return loops to be representative of something believable, i.e. they will be visible and you want them to behave realistically? Consider an alternative: hide them, and allow the trains to stop and start abruptly. Based on experience with Rick's yard, it has never been a problem.

Sokramiketes

  • Crew
  • *
  • Posts: 4974
  • Better modeling through peer pressure...
  • Respect: +1530
    • Modutrak
Re: Back to DC
« Reply #68 on: December 13, 2017, 10:13:28 AM »
0
Just aesthetics.  Seems harsh to just cut the power.  Maybe I should just set it up and see what it looks like in practice. 

Point353

  • Crew
  • *
  • Posts: 3352
  • Respect: +778
Re: Back to DC
« Reply #69 on: December 13, 2017, 12:03:53 PM »
0
Just aesthetics.  Seems harsh to just cut the power.  Maybe I should just set it up and see what it looks like in practice.
If you have a throttle with momentum and a brake switch, then you could have a sensor on the staging track activate a relay, with contacts in parallel with the brake switch, to slow the train down more gradually. Likewise the momentum feature would allow the train to start up more gradually.

As for facilitating different speeds for different trains, if the same train always stops in the same staging siding, then a sensor on that track could activate another relay which selects specific resistor (or potentiometer) values to adjust the throttle speed setting.

C855B

  • Crew
  • *
  • Posts: 10873
  • Respect: +2421
Re: Back to DC
« Reply #70 on: December 13, 2017, 12:50:13 PM »
+3
I've tried hard to stay out of this... however... :D

In my past life as a systems integrator, it came down to the tools available to do the job, plus how much engineering effort it took to implement. If DC alone with a little bit of custom but still simple logic does the job, great. If DCC does the job with off-the-shelf tools, that's great, too. I lean towards the latter, but that's me, where my thinking in the presented scenario is a bit of wheel reinvention going on to solve something already solved. Make vs. buy. I understand that the Z-scale environment might increase complexity relative to installation.

... I believe it can be solved much more effectively by controlling a PWM throttle with a microprocessor. ...

You're suggesting the complexity of custom engineering for an issue already addressed with off-the-shelf solutions available with DCC. I thought the objective here was disposing of DCC as too complex and too quirky for a simple situation, so let's go back to DC. Yet what I'm reading so far is the kind of Rube Goldberg stuff that made me tear my hair (and then the wiring) out on multiple club layouts where somebody "had a better idea".

IMO, reverse loop management and momentum-regulated automated train stops are "shrinkwrapped" solutions... under DCC. A case in point that pushed me over the cliff into DCC for even the simplest of scenarios was a small display layout at the RR museum in Limon, CO. It was a closed figure-8 with at-grade crossing, running two trains, unattended. Classic demolition derby setup. There was detection for the crossing, and (what I now know) was brake-on-DC in the decoders. When the crossing and approach were occupied, the opposite track had a braking block on its approach, apparently switched from DCC to DC on opposite occupancy, with momentum braking in both trains. Worked flawlessly. We were there for about two hours, and I looked in on the layout a few times. No signs of carnage.

As to smart phones as throttles, I use one every day, all day. It works. However, there's a learning curve, not so much the interface, but knowing how it reacts... and where not to rest your thumb. :x  When the time comes for guest operators - they're getting UT4 simple dial throttles.
...mike

http://www.gibboncozadandwestern.com

Note: Images linked in my postings are on an HTTP server, not HTTPS. Enable "mixed content" in your browser to view.

There are over 1000 images on this server. Not changing anytime soon.

DKS

  • The Pitt
  • Crew
  • *
  • Posts: 13424
  • Respect: +7026
Re: Back to DC
« Reply #71 on: December 13, 2017, 01:13:21 PM »
0
You're suggesting the complexity of custom engineering for an issue already addressed with off-the-shelf solutions available with DCC. I thought the objective here was disposing of DCC as too complex and too quirky for a simple situation, so let's go back to DC. Yet what I'm reading so far is the kind of Rube Goldberg stuff that made me tear my hair (and then the wiring) out on multiple club layouts where somebody "had a better idea".

With all due respect, some of us may prefer to tackle what others might regard as a "Rube Goldberg" as being a simpler approach, as counterintuitive as that might seem. For this application, DCC could be considered overkill, it still requires a fair amount of tinkering, and it doesn't do away with its inherent quirkiness (not to mention all of that off-the-shelf gear carries a steep price tag, compared to a bunch of spare parts). If this was a club layout operated by multiple members, then it might not be ideal. But as a one-off for a single operator, I don't see a need for all of the fuss. I'll still prefer to cobble together a handful of relays, a couple of relatively simple custom circuits and a modified throttle than to deal with DCC. But, that's just me. (And maybe a few other oddballs like myself.)
 
« Last Edit: December 13, 2017, 01:22:04 PM by David K. Smith »

DKS

  • The Pitt
  • Crew
  • *
  • Posts: 13424
  • Respect: +7026
Re: Back to DC
« Reply #72 on: December 13, 2017, 01:18:46 PM »
0
Just aesthetics.  Seems harsh to just cut the power.  Maybe I should just set it up and see what it looks like in practice.

Well, again, this is down to what you want from it. If the loops are to remain visible, then yes, a hard stop is harsh. On the other hand, if you want "realism," then the trains will probably need to decelerate for the length of the yard. But if the yards are not part of the scene, the trains won't care if they are controlled this way, especially when operated at realistically slow speeds.

peteski

  • Crew
  • *
  • Posts: 32963
  • Gender: Male
  • Honorary Resident Curmudgeon
  • Respect: +5344
    • Coming (not so) soon...
Re: Back to DC
« Reply #73 on: December 13, 2017, 02:54:33 PM »
0
I understand why many people would belive the path continually leads to DCC. But I never have.

I've considered capacitors as an answer to this for some time as well. But I believe it can be solved much more effectively by controlling a PWM throttle with a microprocessor. (Before microprocessors were prevalent, I built a throttle that was controlled with a geared motor.)

 I stayed silent on this topic until now, but I can't hold back any longer You gave me a good chuckle! You are injecting a processing device and an advanced speed control into the basic pure-DC system.  That is what DCC is (and it is also highly configurable and customizable). The only difference is that your speed control microprocessor and PWM throttle are build-in into each locomotive (for maximum flexibility).  We have come the full circle. But if you want to reinvent the wheel. . .

EDIT: Looks like DKS already addressed this subject and presented his reasoning why it make sense. I still don't see it. Once you start introducing computing devices into a basic DC system you have lost me on how it is a simple old-school solution.  Sorry, I won't buy it.

DCC complicated and overkill?  My "layout" consists of few pieces of Kato Unitrak I set up for testing locos and a $150 NCE power cab all-in-one DCC system.  It plugs into a 120V AC outlet on one side and 2 wires to the track.  Over-complicated?  Really?  Cobbling up a complex relay system with a home-brewed microprocessor speed control and PWM throttle sure seems much more complicated that my ready-to-use NCE PowerCAB.  Call me lazy.  If you are driven by a desire to tinker by yourself then your solution is valid. But don't say that DCC is over-complicated.
« Last Edit: December 13, 2017, 03:06:05 PM by peteski »
. . . 42 . . .

mmagliaro

  • Crew
  • *
  • Posts: 6368
  • Gender: Male
  • Respect: +1871
    • Maxcow Online
Re: Back to DC
« Reply #74 on: December 13, 2017, 03:01:55 PM »
0
I'd have to vote no on a microprocessor.  And believe me, I'm a software developer in my professional life.  But the idea of injecting a computer into an ostensibly "simpler"  all-DC solution utterly turns me off.

A harsh stop, in my view, is just asking for derailment troubles.  I'd avoid this just for that reason.

Is all this added slow-down complexity just so that you can somehow automatically switch the staging tracks, have a train pull in, and another one come out, all without manual intervention?