| |
The following is a good topic for this list. It deals with NXT-to-NXT
messaging. It's based on an original post in the "nxtasy" forums.
There's lots of room for improvement / enhancement in the NXT-to-NXT
messaging. Especially when more that two NXTs are involved -- as in
one master talking to two or three slaves.
I think it is pretty certain that three NXTs (one master and two
slaves) and multiple slaves will not work reliably.
Text from the original post
(http://forums.nxtasy.org/index.php?showtopic=1029) is:
With the help of posts and contacts made in nxtasy, I have succeeded
in getting two NXTs to communicate. Now I want to set up 4 robots. My
idea is to use the master to relay messages. The master 'listens',
sequentially, to mailbox 1, mailbox 2, mailbox 3. When it receives a
message, it sends it using connection 1, 2, or 3. I could add
listening to mailbox 10 for messages intended for the master.
The most I could get working is:
slave 1 (the slave at connection 1) sends a message to the master to
mailbox 1. The master correctly sends that to slave 2. A program on
slave 2 sends a message to the master to mailbox 3. Nothing happens.
It seems like the listening, sequentially checking each of the 3
mailboxes, is happening because a loop counter that calls the polling
MyBlock is incrementing.
The response I wrote is:
Inside the firmware, the "check for message" function does the
following:
1. If BT is idle, launches a polling message to next connection to
retrieve next queued message for desired mailbox. There's an internal
counter (range 1 to 3) that indicates which connection number to use.
NOTE: there's only one internal connection counter indicating the next
connection to check. There's not one counter for each mailbox!
2. Check to see if there is a queued reply message from a previous
poll and return this message in result.
NOTE: the firmware expects a user's program will be frequently calling
the "is message available" function. It uses these calls to provide
execution time to the polling routine. The first time program checks
for a mailbox, it will always return false because there has been no
polling. If your program only checks say once every second, then
you'll only launch a polling message once per second and when a
message is found it will be from the polling message of the previous
second.
It is the call from a user's program to "Message Read" that triggers
the retrieval of a remote mailbox message.
There's ample opportunity for things not to work as expected. This
includes:
1. It will take a long time (300 milliseconds or more) to cycle
through the loop enough times to check all three mailboxes. It will
take at least nine message.
2. Because there's only a single "next connection to poll" field, it
could easily get incremented in a funny pattern so that, for instance,
every time you went to poll mailbox 2 the "next connection" value is
always 3.
3. Suppose you have a "wait 100 msec" at the end of the loop. Then
only mailbox 1 will be polled and the other mailboxes will never be
polled because BT is always busy when it is time to poll.
I suspect you're one of the first people to use multiple mailboxes and
multiple slave NXTs. Otherwise this problem would likely be more
common.
One fix is to only use mailbox 1 and have the mailbox contain an
indicator "field" to indicate the source of the message.
This is all very topical for me, as I'm just finishing adding
messaging support to RobotC. It overcomes many of the limitations
found above with improved algorithms. You might want to give it a try.
Hope this helped.
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
