Code not working right? Here are some things to try. This
list is a summary of questions I've been getting, if you have a different
question, let me know, I'll keep adding to this list.
My module test file isn't sending messages. What is wrong?
Did you comment out the sensors/actuators in Modules.java?
You need to do so for the module tests so that the sensors don't overwrite your
messages.
Also, it may be a problem with your period/size values in Control.java,
Modules.java, and MessagePayload.java.
Since the network sends the highest-priority message first some messages could
wait forever if the network is saturated.
How many AtFloor sensors are there? Are they all
'STOP'?
There are 2 AtFloor sensors for each floor - think of
it like an AtFloor 'zone'. They're all STOP.
I don't think my controller is receiving messages. How can I check this?
You can have your controller print out the messages it is registered for, to
see what the values are.
Run the simulator with network verbose, -nv.
This will print out all the messages on the network (even for module testing).
If the message doesn't show up on the network, then either the .test file is
incorrect or there may be a problem with the simulator (let me know). If the
message shows up on the network then the problem is probably in the controller.
This is the first thing I'll ask you to try if you send me a question, so save
yourself a step :)
Where does the message come from? Make sure you got the network/framework part
right when you register for the message.
I get a weird error from my module test file, something like:
ERROR! (MessageInjector) Exception caught: java.util.NoSuchElementException
ERROR! (MessageInjector) Input test file probably bad.
This could be a lot of things.
Sometimes the simulator doesn't like extra whitespace at the end of the file.
In your .test file, delete all the whitespace after the last line.
Sometimes the simulator doesn't like blank lines. Delete these, or turn it into
a comment line starting with a ;
It may be a comma/no comma thing (see below). Especially if you get a NumberFormatException; the simulator is probably reading
the wrong item and trying to make it into a number.
Don't forget the semicolon for your comments.
Make sure you didn't leave out a field, or put an extra field in.
Should there be commas in the test files?
The integration test files use commas. E.g.:
1.5,1,0,7,1
The module test files do not - just separate fields by a
space or tab.
How do I know what the value is for LEFT, RIGHT, UP, DOWN, STOP, etc.?
You get the value directly from the message payload in question. It's written
in the code just as in the API. For example,
DoorClosedPayload.LEFT
will
give you the value for the left door. This way the actual number used isn't
important. See the API for more details.
The GUI doesn't appear to be working for me. What am I doing wrong?
First, make sure you are not using any other verbose flags. Of course,
the gui should only be used
with integration testing. Finally, try running it from black.ece.cmu.edu
or another color machine. The GUI is a little additional bonus we provide
so that you can really see your simulated elevator move and pick up and drop
off passengers. It is not required for completing the project.
The messages look like they are appearing on the network at the wrong times
for module tests. When do they get released?
Most times the intuitive rules hold for message release times. For
example, if you do:
1.0 0.05 atfloor
1 front false N
Then you should see this network message being enqueued
for delivery at time 1.0, then 1.05, then 1.10 and so on.
However, if you put something kind of strange in your module tests, you'll see
some strange behavior. For example, if you do:
1.01 0.05 atfloor
1 front false N
Then you will see this network message being enqueued
for delivery at time 1.05, then 1,10, and so on. In other words, the
start time is the first time for enqueueing only if
it is a multiple of the period.
You could throw some bizarre messages at the simulator if you are feeling
especially tricky. For example, if you do:
0 0.05 atfloor
1 front false N
8.00 0.08 atfloor
1 front true N
This is bad! Don't do this! I'm not even sure exactly what this
will do, so don't try it. Keep your message periods constant for the same
message type throughout the test. Do this instead:
0 0.05 atfloor
1 front false N
8.00 0.05 atfloor
1 front true N
This is much better. At time 8, the atfloor
message will start to send a true value.