Subject:
|
Re: Help me convert this train program to use events (NQC)
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 28 Nov 2005 18:09:44 GMT
|
Viewed:
|
6513 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Jordan Bradford wrote:
> > > I don't have enough cords to reach the touch sensors...
> >
> > Speaker wire and small alligator clips will make a dandy
> > solution for extending the basic wires...
>
> I wanted the layout to be pure LEGO...
For future, LEGO's educational division does sell 3m LEGO wires.
> I have seen the batteries run down very quickly.
A 1.0 RCX that allows you to power the setup from an outlet is ideal for
this. If it ends up being battery-based, you will have to adjust the power level
as the batteries drain (probably with finer control than just the 8 power levels
the RCX usually allows - but there's ways around this). This to could be
automated, however - record the station-to-station time for the first complete
run, for instance, and if the station-to-station time interval is ever "too
long", have the software readjust the output power.
> I didn't know that low voltage will corrupt the firmware.
> That's good to know for future reference.
i'm not sure if it's low voltage or low current, but the effect is the same:
as the batteries drain, at some point not only does the train crawl, but the
firmware crashes, which is a real problem in the middle of a show (happened to
me twice at BrickFest this year).
> I'd only need one if (the sensor)'s mounted on the train.
Agreed.
> As for the event setup, thanks for the tip. Most every convenience
> function in NQC allows combinations of inputs/outputs.
As does the monitor() command, actually - but you have to be sneaky about it.
You can have one monitor() watch for more than one event like this:
monitor(EVENT_MASK(0) | EVENT_MASK(1))
there are also functions that can return the state of each event, or which
events triggered, so you can distinguish between which of these events tripped
into the catch routine if you need to.
> I was wondering about that monitor block and whether it would only execute
> once. Should I put the monitor block inside a |while(true)| ?
Yes. I cobbled up an (untested!) version of your program using events (before
you decided to go over to touch sensors again). This assumes an on-train RCX
with an on-train light sensoer looking down:
#define eye SENSOR-1
#define train OUT-A
#define STATION-EVT 0
task main()
{
SetSensor(eye, SENSOR_LIGHT);
SetEvent(STATION_EVT, eye, EVENT_TYPE_HIGH);
SetPower(train, OUT_HALF);
while(true)
{
monitor(EVENT_MASK(STATION_EVT))
{
Wait(32767);
}
catch
{
Float(train);
Wait(100);
Toggle(train);
On(train);
Wait(500);
}
}
}
Note that the final "Wait(500)" is so that the train will have time after
reversing to clear the station again - otherwise, the monitor() command will
trip out again as the train reverses over the station.
Use events in this application - it's a nice one to learn on, and if you are
using the standard firmware events are wonderful things to use - the make coding
easier and much faster. And for touch sensors there are EVENT_TYPE_PRESSED or
EVENT_TYPE_RELEASED types that are defined as well.
--
Brian Davis
|
|
Message has 2 Replies:
Message is in Reply To:
16 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
