 | | | | | |
I've always had fun building various roundhouses for my trains. Now for
something bigger - The Roundhouse Project.
I've developed a standard design for a single bay. Each bay can be connected to
another to make a roundhouse with two, three, or as many bays as you might want.
Please take a moment to review the proposed standard and let me know if you have
any questions or concerns:
http://home.teleport.com/~bfleskes/roundhouseproject/TheRoundhouseProject.pdf
A few quick specifics:
Each bay is 74 studs long, 14 studs wide at the front, 28 studs wide at the back
and, represents 11.25 degrees of a circle.
If people agree with the standard and think it's a good idea, I will organize a
gathering of the Roundhouse Project at Brickfest PDX in Feb 2004, in Portland,
Oregon.
Ben Fleskes
PNLTC
| | | | | | | | | | | | | | | | |
| |
|
All,
As I've mentioned before, I have a version of pbForth firmware
for the RCX that allows you to control trains modified with
DCC controllers.
The benefit of pbForth is that you can write, test, and debug
your application interactively using something like a terminal
emulator on your PC.
The other thing is that you don't need to be an expert and
Cygwin guru to install the toolchain. I'll be the first to
admit that pbForth intallation isn't quite as easy as it shold
be either, but I'm working on that.
The questions are these:
How much interest is there in the train community for
truly programmable operation of the train layout?
Is Mark Riley's remote control sufficinet for most needs?
How "pure" a solution to shortcomings like power requirements
and switch control do you need.
As some of you are aware, writing firmware and supporting it
are very time intensive, and I'm reluctant to spend too much
time on this if it's not going to get traction :-)
I'd like to open up some discussion on what kinds of things the
train folks really want to do now, but can't.
Ralph
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.trains, Ralph Hempel wrote:
<snip>
>
> How much interest is there in the train community for
> truly programmable operation of the train layout?
>
> Is Mark Riley's remote control sufficinet for most needs?
>
> How "pure" a solution to shortcomings like power requirements
> and switch control do you need.
>
> As some of you are aware, writing firmware and supporting it
> are very time intensive, and I'm reluctant to spend too much
> time on this if it's not going to get traction :-)
>
> I'd like to open up some discussion on what kinds of things the
> train folks really want to do now, but can't.
>
> Ralph
Now here's a thought--a truly automated layout, such as the following--
The RCX has sensors (either light or magnetic/light (as Jeff Elliot made up) to
detect the trains as they pass) connected to it...
Well, for another way of describing it--I have a layout at home and I'm using
the cross track piece. I have to constantly monitor the trains (fi there are
more than 1) at all times so they don't collide at hte crossover. Speeding up
one, slowing down the other getsw quite tedious, and accidents still happen.
If I write up a program in PBForth that basically runs the layout, and will,
under the right conditions (as sent to it via the sensors) speed up or slow down
individual trains as needed, so such collisions don't happen--a truly automated
layout.
And if, added to that, PBForth is smart enuf to allow 'user intervention', i.e.
with the remote or the wired speed regulators, so that the user can speed up or
slow down individual trains, and yet still be smart enuf to not allow collisions
(all thru programming, of course), that'd be very sweet!
Run Program Q:
Train A starts off at station
Travels to sensor A
Stops (look like it's taking on passengers)
Continues to Sensor B
Stops for more passengers
Continues on...
Train B starts at warehouse 1
Travels to sensor C
Stops, backs up, stops again.
Decoupler separates box car
Train B moves forward to sensor D
...
At crossover
If crossover = train A
and if train B approaching crossover
stop train B
Ooooh... completely automated!
I like it--press "Run" and sit back!
Dave K
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> Ooooh... completely automated!
>
> I like it--press "Run" and sit back!
Dave, don't take ALL the fun out of driving your trains :-)
How about being able to focus on just one train that you
control, but automate things so the OTHER trains don't hit
yours?
Your description was great, except that it involves MANY
sensors, which we all know the RCX is lacking.
The sad thing is, that we don't need all the smarts of a
full light sensor, all we need is "train is here/not here"
sensor. Yes, eventually, it would be neat if we had a
"train #3 is here/not here" but let's take the baby steps first.
As I see it, we can do a couple of things - and since some of
the train guys seem to be leaning away from "pure" LEGO
anyways, maybe we can move things along....
I'm guessing that there is a cheap DCC module that we can use
for things like sensors. If not, all that is really needed
(I think) is a DCC decoder that can use the ACK pulse to
indicate that something is here or not. Smarter sensors
would be able to sense direction too.
With a minimum of 30 msgs/sec and a maximum of about 75-100
the polling of 16 sensors would be no slower than once every
.5 seconds or so.
The nice thing about this would be very little wiring. Just
power the sensor off the track...
Is there another way we can get lots of sensor inputs to
an RCX, or are we better off just buying a "real"" DCC
controller that can be driven from a PC???
Ralph
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.trains, Ralph Hempel wrote:
> I'm guessing that there is a cheap DCC module that we can use
> for things like sensors. If not, all that is really needed
> (I think) is a DCC decoder that can use the ACK pulse to
> indicate that something is here or not. Smarter sensors
> would be able to sense direction too.
>
> With a minimum of 30 msgs/sec and a maximum of about 75-100
> the polling of 16 sensors would be no slower than once every
> .5 seconds or so.
>
> The nice thing about this would be very little wiring. Just
> power the sensor off the track...
The basic DCC ack is defined as an increase of load on
the track of at least 60ma for 6ms +/- 1ms. Normally
this happens on a quiet track where all you have powered
is the decoder being programmed at the time. However, if you
have a bunch or trains on the track, all moving at various
speeds (all using pulse width modulation), the load is going
to be bouncing all over the place and it seems like it would
be difficult to pull the ack signal out of all that noise.
Special headlight effects, like available on the Digitrax
DZ143, could inadvertantly create load patterns that aren't
discernable from an ack.
However, there might be other ways, like introducing a
load the varies at a specific frequency and duration (chosen
to not conflict with the type of load you see from a mobile
decoder). You could use a bandpass filter to pick that
signal out of all the noise.
> Is there another way we can get lots of sensor inputs to
> an RCX, or are we better off just buying a "real"" DCC
> controller that can be driven from a PC???
Well, you can control LDCC from either a PC or even another
RCX (running NQC or BrickOS) using the LDCC IR Protocol.
Look at the bottom of this message for a decription of the
protocol:
http://news.lugnet.com/robotics/rcx/java/?n=269
The zip file for LDCC 1.05 has sample programs for
NQC and BrickOS illustrating the use of the protocol.
Thomas Waadeland has a cool page describing a small
automated layout using a second RCX (running NQC) to
check sensors and control the train using this
protocol (look under Train Control 3):
http://folk.uio.no/thomasw/robotics/creations.html
As Chris mentions, if you want to do automation using
a PC, you can use a Control Lab (or two) to get a lot
of sensor input into the PC and then issue LDCCIRP
commands from the IR tower to the RCX running LDCC.
Sorry if LDCCIRP is old news to you, but in reading
your messages it wasn't clear to me if that was the
case or not.
Cheers,
Mark
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, Mark Riley wrote:
> The basic DCC ack is defined as an increase of load on
> the track of at least 60ma for 6ms +/- 1ms.
So if I understand this correctly, my idea of inserting some kind of
optoisolator or other power driver between the RCX and the track would interfere
with LDCC receiving the ACK signal. Or could the sensor 1 input still be
(safely) connected to the track beyond the driver to read the increased load?
Hmmm...
- Chris.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.trains, Chris Phillips wrote:
> In lugnet.trains, Mark Riley wrote:
> > The basic DCC ack is defined as an increase of load on
> > the track of at least 60ma for 6ms +/- 1ms.
>
> So if I understand this correctly, my idea of inserting some kind of
> optoisolator or other power driver between the RCX and the track would interfere
> with LDCC receiving the ACK signal. Or could the sensor 1 input still be
> (safely) connected to the track beyond the driver to read the increased load?
From what I've read, most DCC layouts have a separate small programming track
anyways. This way a loco can be safely programmed without having to remove all
the other locos from the layout[1]. So, you could hook output A of the RCX to
the booster, and output B could be used on the programming track with the
acknowledgement circuit hooked to sensor 1 (from output B).
Mark
[1] However, operations mode programming does allow a specific loco to be
programmed even with other locos on the track. But, to program the address of
the loco, I think you still need to remove all other locos for that one
programming operation.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> The basic DCC ack is defined as an increase of load on
> the track of at least 60ma for 6ms +/- 1ms. Normally
> this happens on a quiet track where all you have powered
> is the decoder being programmed at the time. However, if you
> have a bunch or trains on the track, all moving at various
> speeds (all using pulse width modulation), the load is going
> to be bouncing all over the place and it seems like it would
> be difficult to pull the ack signal out of all that noise.
> Special headlight effects, like available on the Digitrax
> DZ143, could inadvertantly create load patterns that aren't
> discernable from an ack.
DOH! Of course. In the fire alarm business, we have a three
state voltage out to the sensors. Usually the Vout is 24V and
the device can respond when the voltage falls to 5 V.
The devices have a power supply that is basically a big cap and
a zener diode. When the line voltage is below the zener cutoff
or is lower than the internal cap voltage, the device draws
no current.
That's how we guarantee no other curent is on the wire pair.
> However, there might be other ways, like introducing a
> load the varies at a specific frequency and duration (chosen
> to not conflict with the type of load you see from a mobile
> decoder). You could use a bandpass filter to pick that
> signal out of all the noise.
Yes.
> > Is there another way we can get lots of sensor inputs to
> > an RCX, or are we better off just buying a "real"" DCC
> > controller that can be driven from a PC???
> Sorry if LDCCIRP is old news to you, but in reading
> your messages it wasn't clear to me if that was the
> case or not.
LDCCP is old news to me, but it's good news! I'm trying to promote
pbForth becuase you can program and test stuff interactively.
I've used pbForth to teach kids programming, and adding a fun
thing like a train into the mix just makes it more interesting....
Another way to do it is to add a second DCC channel for things like
sensors. My pbForth does support interleaving DCC messages on
two motor outputs. In other words, send a message on PortA, then
one on PortB, and even PortC for the third one!
Maybe separate motor/sensor buses using DCC are the way to go. That
way the ACK pulses from sensors don't get muddled with motor current?
Ralph
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, Ralph Hempel wrote:
| |
All,
As I’ve mentioned before, I have a version of pbForth firmware
for the RCX that allows you to control trains modified with
DCC controllers.
The benefit of pbForth is that you can write, test, and debug
your application interactively using something like a terminal
emulator on your PC.
The other thing is that you don’t need to be an expert and
Cygwin guru to install the toolchain. I’ll be the first to
admit that pbForth intallation isn’t quite as easy as it shold
be either, but I’m working on that.
The questions are these:
How much interest is there in the train community for
truly programmable operation of the train layout?
Is Mark Riley’s remote control sufficinet for most needs?
How “pure” a solution to shortcomings like power requirements
and switch control do you need.
As some of you are aware, writing firmware and supporting it
are very time intensive, and I’m reluctant to spend too much
time on this if it’s not going to get traction :-)
I’d like to open up some discussion on what kinds of things the
train folks really want to do now, but can’t.
|
I have been working on a different project toward the same end-- improved train
layout automation, and I have had similar questions as to whether it is worth
the effort for the small number of people who might actually benefit from it.
Since the first NELUG train layout, I have used RCXes and reed switches to
detect trains and automate level crossings. For the past several shows, I have
incorporated a laptop computer and a Control Lab interface in order to handle
more crossings without breaking the bank. I’ve only got six RCXes after all! I
wrote a program called TrainLab that displays a bitmap, usually the Track
Designer plan for our layout, and superimposes graphics to show the state of the
reed switches and crossings. This has proven to be a very useful tool in
debugging the train layout during a show.
When Mark Riley released LDCC, I started to adapt my Virtual Remote program to have a user interface that was focused on train
control. When I told Mark about this project, he informed me that he had a
better control protocol in place, so I used that instead of using simple IR
Remote messages. The result is a program that I call
Full Throttle. Since its
release, I’ve had fewer than 30 downloads and have received absolutely no
feedback from anyone about this program, good or bad.
Meanwhile, I have been trying to get TrainLab into shape for release as
freeware. Seeing as I have the code written to control LDCC as well as Control
Labs, RCXes, and other MindStorms hardware, I decided to roll all of this
functionality into TrainLab with a simple event-driven scripting environment
that runs on the PC. The new-and-improved TrainLab will still have the ability
to control level crossings and display bitmaps, but it will also be easily
extended to perform other types of automation. It will be able to address a DCC
train engine as easily as it commands a Control Lab motor output. I have much
of the raw functionality for this new utility working today. In fact, I used
the latest incarnation of this program on last weekend’s NELUG train layout at
the Greenberg Train Show, and it worked just fine.
Still, I have come to question whether it is worth the additional time and
effort to improve the user interface, fix all of the obscure bugs, and document
this program given the very limited size of the audience that I have seen so
far, and also given their apparently limited interest in providing feedback that
will help me to further refine these programs. Especially when I balance it
against the time demands of some of my other projects that might be of benefit
to a wider audience. I suspect (but certainly do not know) that you will find
the same thing.
Granted, my programs do not come close to being as cool or ground-breaking as
LDCC itself, so I don’t expect people to be dropping out of trees to
congratulate me or thank me for my efforts. But when you release free software
into the ether and hear nothing but crickets chirping, you begin to wonder if
anybody is using it at all.
Personally, I would love to see more alternatives for railroad automation, such
as an enhanced pbForth would provide, and I should be the last person to
discourage you from following this path. I will happily try out anything you
would care to release, and I vow to give you better feedback than I have gotten
from the train community. Sorry to sound negative, but I’m just relaying my own
experience.
To answer some of your other questions, I can see a need for a couple of pieces
of “impure” hardware before DCC will be fully useful on a LEGO train layout.
One would be a simple driver circuit that would take the low-current output from
an RCX and switch the polarity of a high-current DC source such as a train
transformer so that LDCC could be used without fear of damaging the RCX. This
would also make LDCC work on a 2.0 RCX that doesn’t have the AC power input
jack. I think something like this could easily be built using a few MOSFET
transistors or opto-isolators or some other rapid-switching devices. Another
piece of hardware that any DCC-head could easily make would be a stand-alone DCC
decoder packaged in a 2x4 brick which could be used to run the motors of
automated switch points, roundhouses, decouplers, or other motorized or lighted
trackside structures.
- Chris.
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, Chris Phillips wrote:
snip
| |
Full Throttle. Since its
release, I’ve had fewer than 30 downloads and have received absolutely no
feedback from anyone about this program, good or bad.
|
snip
I know that I was one of those 30, Chris--sorry about not getting back to you.
I d/led it but never actually used it yet :( So busy just getting a layout up
and running--making buildings, etc :)
I do plan on using the software, mayhaps this weekend :)
As an addendum, I’ve noticed that LDCC didn’t ‘catch on’ as much as I
anticipated. I know I’ve been running it exclusively on my layout at home since
Mark released it, and at NMRA, rtlT used it on the layout there. Even at the
hobby show LDCC was used most of the time. I think the thing is that we only
have 2, maybe 3 trains going at any given time, and all those can be handledfrom
the remote--full throttle, for 9 trains, isn’t to our ‘scale’ range (yet :) )
But I will honestly give it a go this weekend. It’s here on my laptop right
now, and I have 2 modified motors, and am planning to get a few more chips this
weekend so I can convert at least 3 of my 4 remaining DC motors to DCC.
Anyway, there are DCC users out there, and I believe, in the future, there will
be Full Throttle users for the larger layouts.
Dave K
now your software for reed switches and TD layouts sounds very interesting :)
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, David Koudys wrote:
snip
| |
I know that I was one of those 30, Chris--sorry about not getting back to
you.
I d/led it but never actually used it yet :( So busy just getting a layout
up and running--making buildings, etc :)
I do plan on using the software, mayhaps this weekend :)
|
snip
This weekend was exceptionally busy, but I had time to play with the layout.
Took my laptop downstairs, set it up with the IR tower, and loaded up Full
Throttle.
Wow! Pretty nifty piece of work, Chris! With only 2 DCC locos I didn’t task
the software, but still, in all, it did a magnificent job!
Maybe at our next rtlT train show we’ll put the software to the big test, with
mltiple locos ‘n such.
I also stopped by he local hobby show and attempted to buy DCC chips. Since the
hobby show took most of their stock to the train show in Toronto (which we
rtlers didn’t get to), there wasn’t much in the way of DCC chips there. But
they had one HO so I bought that, and cut up an electrical plate and soldered it
all together. Didn’t work at all with LDCC :(
Either the chips fried, or it doesn’t like the LDCC. Tested my connections and
soldering extensively last night and still nada. Will take the chip back to the
store and see what they have to say.
So my excursion into the realm of DCC accessories will have to wait ‘til tonight
:(
Dave K
| | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, Chris Phillips wrote:
snip
| |
devices. Another piece of hardware that any DCC-head could easily make would
be a stand-alone DCC decoder packaged in a 2x4 brick which could be used to
run the motors of automated switch points, roundhouses, decouplers, or other
motorized or lighted trackside structures.
- Chris.
|
I’m just going thru my mind (which is always a bad idea), and this would be, as
stated, very easy--
My DCC chip has motor out, and 2 light wires out. Connect ‘em to a electric
plate and we’re good to go!
Lets see--you’ll need a 2x2 electric plate for the connector to the tracks, a
2x2 electric plate for the motour out, and maybe each light out can have a
separate 2x2 electric plate, or, like in my trains, the light outs are tied
together (one wire is on when the train is moving forward, the other light wire
is for when the trian is moving in reverse)...
So 2x6 is what I’d use, and that’ll fit an HO decoder (which is much cheaper
than the N scale I have inside my train motors...)
I’ll hopefully try that this weekend as well--trip to the hobby store coming up!
(if finances can be found :) )
Dave K
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, David Koudys wrote:
| |
In lugnet.trains, Chris Phillips wrote:
snip
| |
Another piece of hardware that any DCC-head could easily make
would be a stand-alone DCC decoder packaged in a 2x4 brick which could be
used to run the motors of automated switch points, roundhouses, decouplers,
or other motorized or lighted trackside structures.
- Chris.
|
I’m just going thru my mind (which is always a bad idea), and this would be,
as stated, very easy--
My DCC chip has motor out, and 2 light wires out. Connect ‘em to a electric
plate and we’re good to go!
Lets see--you’ll need a 2x2 electric plate for the connector to the tracks, a
2x2 electric plate for the motour out, and maybe each light out can have a
separate 2x2 electric plate, or, like in my trains, the light outs are tied
together (one wire is on when the train is moving forward, the other light
wire is for when the trian is moving in reverse)...
So 2x6 is what I’d use, and that’ll fit an HO decoder (which is much cheaper
than the N scale I have inside my train motors...)
I’ll hopefully try that this weekend as well--trip to the hobby store coming
up! (if finances can be found :) )
|
Cool. I think that this is the key to getting DCC into wider use. After all,
there are only so many trains that will fit onto a layout unless it is truly
massive. But there are a lot of potentially motorized items on a layout that
could be treated like just another loco in the DCC scheme of things. If the
issues of power draw through the RCX can be resolved, more decoders can be used
on the layout, and a single RCX would be capable of driving them all. Much
cheaper to add a $20 decoder to your layout than a $200 RCX. And then this
would allow all of the logic for all of the automation to work together in a
cohesive fashion, as Ralph has suggested.
- Chris.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.trains, Chris Phillips wrote:
| |
In lugnet.trains, David Koudys wrote:
| |
In lugnet.trains, Chris Phillips wrote:
snip
| |
Another piece of hardware that any DCC-head could easily make
would be a stand-alone DCC decoder packaged in a 2x4 brick which could be
used to run the motors of automated switch points, roundhouses, decouplers,
or other motorized or lighted trackside structures.
- Chris.
|
I’m just going thru my mind (which is always a bad idea), and this would be,
as stated, very easy--
My DCC chip has motor out, and 2 light wires out. Connect ‘em to a electric
plate and we’re good to go!
Lets see--you’ll need a 2x2 electric plate for the connector to the tracks,
a 2x2 electric plate for the motour out, and maybe each light out can have a
separate 2x2 electric plate, or, like in my trains, the light outs are tied
together (one wire is on when the train is moving forward, the other light
wire is for when the trian is moving in reverse)...
So 2x6 is what I’d use, and that’ll fit an HO decoder (which is much cheaper
than the N scale I have inside my train motors...)
I’ll hopefully try that this weekend as well--trip to the hobby store coming
up! (if finances can be found :) )
|
Cool. I think that this is the key to getting DCC into wider use. After
all, there are only so many trains that will fit onto a layout unless it is
truly massive. But there are a lot of potentially motorized items on a
layout that could be treated like just another loco in the DCC scheme of
things. If the issues of power draw through the RCX can be resolved, more
decoders can be used on the layout, and a single RCX would be capable of
driving them all. Much cheaper to add a $20 decoder to your layout than a
$200 RCX. And then this would allow all of the logic for all of the
automation to work together in a cohesive fashion, as Ralph has suggested.
|
Yes, sounds like fun! And, that DZ123 I recently posted about would be ideal
for the job. I think I’ll have to order one or two more to test this out. One
change to LDCC that would help facilitate this would be the ability to configure
LDCC to know which switches are being powered by accessory decoders vs. mobile
decoders. That way, you could tell LDCC to throw a switch (using the remote or
via LDCCIRP) and it would send the appropriate commands based on the type of
switch decoder.
Also, these mobile decoders wouldn’t be drawing all that much power unless they
were actually in the process of throwing a switch, so I think the RCX wouldn’t
be burdened too much (plus you can always use additional RCXs as boosters if
there is a problem).
Mark
| | | | | | | | | | | | | | | | | | | | | | | | |
I realize this thread is kinda old but ...does anyone know if Chris Phillips
ever made his TrainLab software available? I have tried a few times to contact
Chris without any success. I have been looking into automating my train layouts
and would love to be able to use the Control Lab interface. I suppose that with
some effort (and programming skills) I could use Robolab to create an automated
train control program.
| | | | | | | | | | | | | | | | | | |
| |
|
Ben Fleskes wrote:
> I've always had fun building various roundhouses for my trains. Now for
> something bigger - The Roundhouse Project.
>
> I've developed a standard design for a single bay. Each bay can be
> connected to another to make a roundhouse with two, three, or as many bays
> as you might want.
> Each bay is 74 studs long, 14 studs wide at the front, 28 studs wide at
> the back and, represents 11.25 degrees of a circle.
>
> If people agree with the standard and think it's a good idea, I will
> organize a gathering of the Roundhouse Project at Brickfest PDX in Feb
> 2004, in Portland, Oregon.
The idea is solid. However if I check the pictures of the first models the
height is too low for many models... I'd make it at least 2 bricks higher,
the LEGO Caboose might do nice as a try-out, or the 4551 with panto's up.
Also, what happens with large 8-wide trains? They might have objects
pointing out making for a total width of 10-11 studs... perhaps increasing
the distance from the front to the turntable a bit to make the front wider?
--
Jan-Albert van Ree | http://www.vanree.net/brickpiles/
Brick Piles | Santa Fe B-unit
| | | | | | |
