Subject:
|
Re: Transmitting a message from the RCX to the PC
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Thu, 22 May 2003 21:24:08 GMT
|
Viewed:
|
3219 times
|
| |
|
|
In lugnet.robotics.rcx, Steven Lane writes:
> In lugnet.robotics.rcx, Chris Phillips writes:
> > In lugnet.robotics.rcx, Michael Franklin Bosu writes:
>
>
> > Since you have still not provided more information about the programming
> > language/environment you are using or any details about your intended
> > application, it is difficult for anyone to provide you with a more detailed
> > response. Instead of re-posting the same question every few days, you will
> > get better results if you give us more to work with.
>
> I'm not the originator of this thread but I am interested in the same problem.
>
> I'm intending to use
>
> MS visual c++ V4
> spirt.ocx
> RIS 2.0 firmware
> and NQC
>
> > Perhaps a better way to get information from the RCX to the PC is to have
> > the PC poll the RCX. Using the standard RCX firmware, you can store a data
> > value in one of the 32 program variables, then have the PC periodically send
> > an "interrogate variable value" opcode to the RCX. The RCX will respond by
> > sending back the 16-bit value in that variable. This will NOT work if you
> > have more than one RCX in the room, since they will all try to respond to
> > the PC poll and will walk all over each others' transmissions.
>
> I do want to use two RCX's though.
>
> My plan is to have RCX No 2 send data to RCX No 1. RCX No 1 will then
> forward this data along with it's own to the PC which will process it and
> then send a response just to RCX No 1. RCX 1 will then signal RCX 2 to begin
> the cycle again.
>
> Couldn't I just tell RCX 2 to shut down comms for a short while so it would
> not interfere with RCX 1's comms to the PC?
I am not sure if there is a way to disable the communications on the RCX
when using the standard firmware. You could try putting an aluminum foil
blinder around RCX No 2's IR transceiver, but I've found IR notoriously
difficult to block since it bounces off walls and even penetrates solid LEGO
boxes. You might also want to try configuring No 2 for short range IR mode,
although I am pretty sure that this only affects the strength of its
transmissions, not the sensitivity of its receiver.
If you're using the standard firmware, you probably still will need to poll
RCX variables from the PC, though. You could use one-byte messages for all
master-slave communications, and periodically poll a pair of variables in
the master RCX from the PC. You would poll the first variable to get some
kind of count that would indicate whether new data is available, then read
the second variable to get the actual data value. You could get away with
reading just a single variable if you either don't care whether the data has
been updated, or can pack both pieces of information (frame count and a data
value for that frame) into a single 16-bit variable. Also remember that
your NQC program on the master will not have any indication of when the PC
has polled a variable, so if the master needs to know when that has occurred
you'll need to set up some other signal.
This might be a good application for the data logger, because the master
could just log data points until the next poll interval. The PC would
upload (and possibly reset) the datalog instead of reading variables.
Because of the added communication load of this approach, this would be
best-suited to an application where the PC doesn't need to poll very often,
and can get away with waiting several seconds (or minutes) between uploads.
You still have the problem that the PC could poll at an inconvenient time
and end up stomping all over the master-slave communications. You might be
able to come up with a protocol based on one-byte messaging that would
establish safe windows for RCX messaging, etc., but the effort you put into
that would depend on how serious the consequences of the occasional dropped
slave message might be.
You provided some good information, but can you describe what you are
actually trying to do with this setup? It is really a lot harder for anyone
to offer useful advice without knowing what the application is, what you've
already tried, what other design constraints are in place, etc.
- Chris.
|
|
Message is in Reply To:
 | | Re: Transmitting a message from the RCX to the PC
|
| (...) I'm not the originator of this thread but I am interested in the same problem. I'm intending to use MS visual c++ V4 spirt.ocx RIS 2.0 firmware and NQC (...) I do want to use two RCX's though. My plan is to have RCX No 2 send data to RCX No 1. (...) (21 years ago, 22-May-03, to lugnet.robotics.rcx)
|
11 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
