 | | | | | | |
| |
|
You want some fun?? Try this some time--
Take one RCX (preferably with AC adapter)
Take one Train track connecting wire.
Connect wire to Port A (or B or C--matters not)
Connect leads to train track
Put locomotive on train track.
Now, get a RCX remote and push the 'up' arrow for A
Watch locomotive careen off track and smash onto floor...
For some reason, the motor outputs on an RCX have alot more power than a train
regulator set to 'full'.
This I did not know.
The second thing I did not know--
Program your RCX with a little NQC and set motor speed to 1 (just 1 above 0,
which is basically off)
Run the program.
Watch your locomotive careen off the track and smash onto the floor.
Yes, even at speed 1, the train motors are exceptionally fast.
I don't think the train motors are set up the same way as the 'geared' motors.
Now a modified train motor (a DCC'ed one) will rum pretty stable on an RCX'ed
track. It runs at basically the same speed, no matter what speed you set in
your NQC program, but I can live with that.
What I may do, seeing as how I basically have no speed control over train motors
with the RCX connected directly to the track and running NQC, is to do the 'Mark
Riley' thing and have LDCC connected to the track, but taking commands from
another RCX running NQC. I was hoping to not do that, considering that IR
communications really does suck. As well, having the sensor inputs and the
motor outputs for everything plugged into 1 RCX was so convenient...
Eh, the trials and tribulations of building...
Dave K
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.org.ca.rtltoronto, David Koudys wrote:
> Watch locomotive careen off track and smash onto floor...
hehe. Yeah, when my son & I got our first train, we ran it off the regulator
for about 30 seconds before trying the RCX thing. The next 10 minutes was spent
seeing who could "throw" the train motor the furthest.
> Program your RCX with a little NQC and set motor speed
> to 1... Watch your locomotive careen off the track and
> smash onto the floor.
Hmm. As I recall, I could run a train (*not* just the train motor) at power
levels of up to 3 before it jumped the track, but perhaps I'm mis-remembering.
> What I may do, seeing as how I basically have no speed
> control over train motors with the RCX connected directly
> to the track and running NQC, is to do the 'Mark
> Riley' thing and have LDCC connected to the track, but
> taking commands from another RCX running NQC.
Well, for the GBC trains at BrickFest neither Steve nor I did anything with
LDCC (we talked about it, but found we could do without). I used NQC, and Steve
used BrickOS, and both of us had reasonably could speed and positioning control.
What are you trying to do?
--
Brian Davis
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.org.ca.rtltoronto, Brian Davis wrote:
<snip>
> Well, for the GBC trains at BrickFest neither Steve nor I did anything with
> LDCC (we talked about it, but found we could do without). I used NQC, and Steve
> used BrickOS, and both of us had reasonably could speed and positioning control.
> What are you trying to do?
I think there are a few variables--I saw the videos of the GBC--that's what
inspired me, btw--and it's a pretty big loop--therefore more resistance in the
rails.
I'm running a pretty small loop with a prety small train.
Actually, you can see the loop here--
http://sparky.i989.net/blog/00000281.php
It's that upper portion--the issue is, the train has to go around and back up
into the sidings. Hard to control on such a small section of track--it's too
fast when it hits the touch sensor at the ends of the sidings.
I was going to go with the light sensors, as I think the GBC does--that works
well on the loop 'cause the train shoots past the light sensor on the loop, then
backs up.
The problem wit hthe siding is that I don't have alotta room for 'slowdown'
room, though that is the direction I'm heading in.
That also means I'll need 4 light sensors just for the upper loop.
I'm going to do more this weekend nad I'll keep y'all apprised.
If it doesn't work, then it's LDCC IR'ed to an NQC'd RCX
Dave K
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
David Koudys wrote:
> In lugnet.org.ca.rtltoronto, Brian Davis wrote:
>
> <snip>
>
> > Well, for the GBC trains at BrickFest neither Steve nor I did anything with
> > LDCC (we talked about it, but found we could do without). I used NQC, and Steve
> > used BrickOS, and both of us had reasonably could speed and positioning control.
> > What are you trying to do?
>
>
> I think there are a few variables--I saw the videos of the GBC--that's what
> inspired me, btw--and it's a pretty big loop--therefore more resistance in the
> rails.
>
> I'm running a pretty small loop with a prety small train.
>
> Actually, you can see the loop here--
>
> http://sparky.i989.net/blog/00000281.php
>
> It's that upper portion--the issue is, the train has to go around and back up
> into the sidings. Hard to control on such a small section of track--it's too
> fast when it hits the touch sensor at the ends of the sidings.
>
> I was going to go with the light sensors, as I think the GBC does--that works
> well on the loop 'cause the train shoots past the light sensor on the loop, then
> backs up.
>
> The problem wit hthe siding is that I don't have alotta room for 'slowdown'
> room, though that is the direction I'm heading in.
>
> That also means I'll need 4 light sensors just for the upper loop.
>
> I'm going to do more this weekend nad I'll keep y'all apprised.
>
> If it doesn't work, then it's LDCC IR'ed to an NQC'd RCX
>
> Dave K
have you tried making your own PWM speed setting in NQC?
5 X = ?? Y = ??
10 ? CLR
20 motor A ON
30 wait x
40 motor A OFF
50 wait Y
60 goto 20
Man I wish NQC was that easy.
either way you get the idea. you can PWM the RCX yourself and control
both the ON and OFF times to change the "speed"
Chris
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.org.ca.rtltoronto, Chris Magno wrote:
> David Koudys wrote:
> > I saw the videos of the GBC--that's what inspired
> > me, btw
Cool to know.
> > the train has to go around and back up into the
> > sidings. Hard to control on such a small section
> > of track--it's too fast when it hits the touch
> > sensor at the ends of the sidings.
Then you need another bank of sensors, perhaps, to tell you when a train is
coming "near" the siding, for instance. Cruise speed until near a siding, then
slow speed to approach siding, and finally "creeping" speed to position on the
siding.
> > I was going to go with the light sensors, as I
> > think the GBC does...
Actually the GBC trains use NC touch sensors, although you could design NO
touch sensors as well, and those would be easily stackable. Each GBC hopper car
had a 2x2 cylinder mounted below the train baseplate that stuck out 1 stud
beyond the 6-wide limit, enough to hit an arm that tripped the touch sensor.
Visually these were not distracting (most people had to have them pointed out),
and worked well.
Light sensors would work, but aren't stackable, and are harder to interprete.
Since your application is a raised track, a touch sensor assembly could be
nicely hidden below the track, activated by the wheel bogies (or, perhaps
better, the flat bottom of the train motor bogie) - six wide, and hidden.
I *like* the idea of an "automated" layout moving materials around, BTW.
Maybe standards could be set up so others could unload what your set-up loads
and "ships" to othe parts of the layout.
> > If it doesn't work, then it's LDCC IR'ed to an NQC'd RCX
How "big" is LDCC? I'm *not* a coder, but it seems to me some enterprizing
soul could make a LDCC add-on for BrickOS, for instance, or the Swan firmware.
that way you could have LDCC as an "output format" on an RCX that otherwise is
just running "normal" RCX programs. Fully programmable, autonomous LDCC.
Chris wrote:
> have you tried making your own PWM speed setting in NQC?
>
> 5 X = ?? Y = ??
> 10 ? CLR
> 20 motor A ON
> 30 wait x
> 40 motor A OFF
> 50 wait Y
> 60 goto 20
>
> Man I wish NQC was that easy.
It is. But instead of Wait(var), you have to watch a timer. And it turns out,
not only is Wait() too slow, but it's not very accurate for short times. Another
way of doing it (in NQC) is this:
task engineer()
{
while(true)
{
while(power != 0 )
{
On(OUT_A);
if(power==1) Off(OUT_A);
if(power==2) Off(OUT_A);
if(power==3) Off(OUT_A);
<etc.>
}
Off(OUT_A);
}
}
Now just have the main task run the train by changing the value of the global
variable "power". If you need all the power levels to be slightly higher (more
time spent "on"), add some sort of effective "nop" right after the On(OUT_A)
command, but *not* Wait(1) - it sucks for this. Need an overall slightly lower
power? Add "nop"s right after the Off(OUT_A) command.
--
Brian Davis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Brian Davis wrote:
> In lugnet.org.ca.rtltoronto, Chris Magno wrote:
>
>
> > David Koudys wrote:
> >
> > > I saw the videos of the GBC--that's what inspired
> > > me, btw
>
>
> Cool to know.
>
>
> > > the train has to go around and back up into the
> > > sidings. Hard to control on such a small section
> > > of track--it's too fast when it hits the touch
> > > sensor at the ends of the sidings.
>
>
> Then you need another bank of sensors, perhaps, to tell you when a train is
> coming "near" the siding, for instance. Cruise speed until near a siding, then
> slow speed to approach siding, and finally "creeping" speed to position on the
> siding.
>
>
> > > I was going to go with the light sensors, as I
> > > think the GBC does...
>
>
> Actually the GBC trains use NC touch sensors, although you could design NO
> touch sensors as well, and those would be easily stackable. Each GBC hopper car
> had a 2x2 cylinder mounted below the train baseplate that stuck out 1 stud
> beyond the 6-wide limit, enough to hit an arm that tripped the touch sensor.
> Visually these were not distracting (most people had to have them pointed out),
> and worked well.
> Light sensors would work, but aren't stackable, and are harder to interprete.
> Since your application is a raised track, a touch sensor assembly could be
> nicely hidden below the track, activated by the wheel bogies (or, perhaps
> better, the flat bottom of the train motor bogie) - six wide, and hidden.
> I *like* the idea of an "automated" layout moving materials around, BTW.
> Maybe standards could be set up so others could unload what your set-up loads
> and "ships" to othe parts of the layout.
>
>
> > > If it doesn't work, then it's LDCC IR'ed to an NQC'd RCX
>
>
> How "big" is LDCC? I'm *not* a coder, but it seems to me some enterprizing
> soul could make a LDCC add-on for BrickOS, for instance, or the Swan firmware.
> that way you could have LDCC as an "output format" on an RCX that otherwise is
> just running "normal" RCX programs. Fully programmable, autonomous LDCC.
>
> Chris wrote:
>
>
> > have you tried making your own PWM speed setting in NQC?
> >
> > 5 X = ?? Y = ??
> > 10 ? CLR
> > 20 motor A ON
> > 30 wait x
> > 40 motor A OFF
> > 50 wait Y
> > 60 goto 20
> >
> > Man I wish NQC was that easy.
>
>
> It is. But instead of Wait(var), you have to watch a timer. And it turns out,
> not only is Wait() too slow, but it's not very accurate for short times. Another
> way of doing it (in NQC) is this:
>
> task engineer()
> {
> while(true)
> {
> while(power != 0 )
> {
> On(OUT_A);
> if(power==1) Off(OUT_A);
> if(power==2) Off(OUT_A);
> if(power==3) Off(OUT_A);
> <etc.>
> }
> Off(OUT_A);
> }
> }
>
> Now just have the main task run the train by changing the value of the global
> variable "power". If you need all the power levels to be slightly higher (more
> time spent "on"), add some sort of effective "nop" right after the On(OUT_A)
> command, but *not* Wait(1) - it sucks for this. Need an overall slightly lower
> power? Add "nop"s right after the Off(OUT_A) command.
sorry Brian, I stand by my original statement, I WISH "C" was as easy
to grok as BASIC.
My understanding from Dave, was that he was just looking for a way to
slow an unloaded car down. Either way, software exists to "roll your
own" PWM.
as to train detecting, Didn't jeff E come up with an all lego way to
mount a LX sensor in an enclosed space and had it "triggered" by the
magnets of the couplers? IIRC it was very sensitive.(1)
(found it)
http://news.lugnet.com/org/ca/rtltoronto/?n=7281
Chris
1. not that i was insulting to the bricks, they just arent as thick
skinned.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chris Magno wrote:
> as to train detecting, Didn't jeff E come up with an all lego way to
> mount a LX sensor in an enclosed space and had it "triggered" by the
> magnets of the couplers? IIRC it was very sensitive.(1)
>
> (found it)
>
> http://news.lugnet.com/org/ca/rtltoronto/?n=7281
Ya, I used this very successfully to run crossing gates in the Altenburg
layout. They can also be constructed to sit beside the track if you
don't space under the track.
Derek
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.org.ca.rtltoronto, Brian Davis wrote:
> How "big" is LDCC? I'm *not* a coder, but it seems to me some enterprizing
> soul could make a LDCC add-on for BrickOS, for instance, or the Swan firmware.
> that way you could have LDCC as an "output format" on an RCX that otherwise is
> just running "normal" RCX programs. Fully programmable, autonomous LDCC.
No need to write it, it already exists! Find it here:
http://home.surewest.net/markril/lego/dcc/dcc.tar.gz
I never got around to actually posting this code in a public place as I've just
emailed it directly to interested individuals. Anyways, there's a patch to
BrickOS, the DCC routines themselves and a small demo program in C for
controlling a locomotive to illustrate usage of the routines.
Cheers,
Mark
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.org.ca.rtltoronto, Mark Riley wrote:
> In lugnet.org.ca.rtltoronto, Brian Davis wrote:
>
> > How "big" is LDCC? I'm *not* a coder, but it seems to me some enterprizing
> > soul could make a LDCC add-on for BrickOS, for instance, or the Swan firmware.
> > that way you could have LDCC as an "output format" on an RCX that otherwise is
> > just running "normal" RCX programs. Fully programmable, autonomous LDCC.
>
> No need to write it, it already exists! Find it here:
>
> http://home.surewest.net/markril/lego/dcc/dcc.tar.gz
>
> I never got around to actually posting this code in a public place as I've just
> emailed it directly to interested individuals. Anyways, there's a patch to
> BrickOS, the DCC routines themselves and a small demo program in C for
> controlling a locomotive to illustrate usage of the routines.
>
> Cheers,
>
> Mark
Hey Mark,
I've been using LDCC for a while now--very happy with it, btw...
Anyway, you say you have thins thing for BrickOS-I've never used that--I only
program in NQC
Is this routine adaptable to NQC so I can have NQC and LDCC running on the same
RCX or do I have to use the IR transmission as outlined in LDCC 1.05?
Dave K
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.org.ca.rtltoronto, David Koudys wrote:
> I've been using LDCC for a while now--very happy with it, btw...
>
> Anyway, you say you have thins thing for BrickOS-I've never used that--I only
> program in NQC
>
> Is this routine adaptable to NQC so I can have NQC and LDCC running on the same
> RCX or do I have to use the IR transmission as outlined in LDCC 1.05?
Well, you couldn't translate the DCC routines to NQC (if that's what you're
asking) because the byte code interpreter used by NQC is simply too slow to
generate the correct waveform (by a factor of about 1000!) The DCC routines
were written in H8 assembly code at the firmware level. BTW, the assembly
source code for the routines is provided in the tarball I linked to upthread if
anyone is willing to take a crack at adding DCC to any of the other firmware
options out there.
But, yeah, at present if you want to write code in NQC you'll have to use a
second RCX and send IR packets to the RCX running LDCC.
Mark
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.org.ca.rtltoronto, Chris Magno wrote:
<snip>
>
> have you tried making your own PWM speed setting in NQC?
>
> 5 X = ?? Y = ??
> 10 ? CLR
> 20 motor A ON
> 30 wait x
> 40 motor A OFF
> 50 wait Y
> 60 goto 20
>
>
> Man I wish NQC was that easy.
>
> either way you get the idea. you can PWM the RCX yourself and control
> both the ON and OFF times to change the "speed"
>
> Chris
See, this is why I like Chris--we both think along the same lines...
I did try this, with various delays on power on and power off--eitehr the train
is too jumpy, doesn't move, or still shoots around the track.
Eh...
Dave K
| | | | | | | | | | | | | | | | | | | |
| |
|
On Fri, October 14, 2005 10:04 am, David Koudys wrote:
> You want some fun?? Try this some time--
...
>
> Watch locomotive careen off track and smash onto floor...
...
>
> Watch your locomotive careen off the track and smash onto the floor.
>
> Yes, even at speed 1, the train motors are exceptionally fast.
Add cars to the train. Then, the speeds will make more of a difference.
If you're using the Swan firmware, you may have more control over the motor speed.
I think there's a setting for power/break instead of the normal power/float.
Check into Swan Firmware power levels...
Here are some videos from a GBC we're making for a train layout for this weekend:
(The length of the video on the page is not correct.)
http://www.ffni.com/~kerby/gbc/index.htm
We used touch sensors that hit the train cars, as the cars go by. Here are the cars:
http://www.teamhassenplug.org/GBC/Train/
The blue round 2x2 brick on bottom hits the arm with the touch sensor.
In our GBC @ BF, we actually could attach an unlimited number of stations to each
RCX. But that's another matter.
Steve
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.org.ca.rtltoronto, David Koudys wrote:
> You want some fun?? Try this some time--
>
> Take one RCX (preferably with AC adapter)
>
> Take one Train track connecting wire.
>
> Connect wire to Port A (or B or C--matters not)
>
> Connect leads to train track
>
> Put locomotive on train track.
>
> Now, get a RCX remote and push the 'up' arrow for A
>
> Watch locomotive careen off track and smash onto floor...
We have been using an RCX to control trains running back and forth on a track
which has a terminus at each end, not a loop. (To make this sensorless, there
are diodes inserted in the track at each end so trains can power out of the
station, not into it. This causes them to coast nicely to a halt in the
station.)
The thing is, although a motor by itself will go way too fast, when it is
pulling a whole train of cars, that won't happen. I usually have to run NQC with
power set in the 3 - 5 area.
What I ended up doing was a simple timing sequence which applies higher power
for a few seconds to get the train moving, then coasts on straights at lower
power and adds a little power for the corners. (I tune the timing for each
layout. It usually only takes 20 minutes or so to get it just so.) The train
typically takes 10 - 15 seconds to get from one end of the track to the other.
The RCX reverses the direction every 30 seconds or so which makes the train sit
in the station for the right amount of time.
So I'd say don't give up on the RCX as a train controller. It works great for
me. Ver. 1.0 with the A/C power connector of course.
JB
| | | | | | | | | | | | | | | | |
In lugnet.org.ca.rtltoronto, David Koudys wrote:
> You want some fun?? Try this some time--
[snip]
>
> What I may do, seeing as how I basically have no speed control over train motors
> with the RCX connected directly to the track and running NQC, is to do the 'Mark
> Riley' thing and have LDCC connected to the track, but taking commands from
> another RCX running NQC. I was hoping to not do that, considering that IR
> communications really does suck. As well, having the sensor inputs and the
> motor outputs for everything plugged into 1 RCX was so convenient...
Try adding a few lights on to the output in addition to the track connector -
this will use some of the power and slow the train down. I think this is what
Tom Cook did to slow down some RCX controled trolleys that we had in a layout a
few years ago.
Some early electric train sets used light bulbs as speed controlers - the more
bulbs that were unscrewed, the faster the train would go.
Bob
| | | | | | | | | | | | | | | | |
In lugnet.org.ca.rtltoronto, Bob Hayes wrote:
<snip>
>
>
> Try adding a few lights on to the output in addition to the track connector -
> this will use some of the power and slow the train down. I think this is what
> Tom Cook did to slow down some RCX controled trolleys that we had in a layout a
> few years ago.
>
> Some early electric train sets used light bulbs as speed controlers - the more
> bulbs that were unscrewed, the faster the train would go.
>
> Bob
Thanks for the idea--remembered that from the LDCC motor-to-sensor port wiring
thingy, so tried it.
Put 2 lights--not much difference. Put a stack of 3 lights on a side (6
lights), little difference.
Eh, it'll work with a DCC'd train motor--I'm going to try the light sensor when
I get home, as well as a few other ideas from this thread.
Thanks for the ideas!
Dave K
| | | | | | |
