Send AMD when AME is received #205
Conversation
| @@ -88,6 +88,13 @@ public void processFrame(OpenLcbCanFrame f) { | |||
| return; // as a convenience, ignore | |||
| } | |||
|
|
|||
| if (f.isAliasMapDefinition()) { | |||
There was a problem hiding this comment.
Shouldn't this be testing for enquiry?
Also we need to verify that the payload of the enquiry is empty or matches our node ID.
There was a problem hiding this comment.
Thanks. Done, I think.
There was a problem hiding this comment.
I think this code is now correct. I would be happy to approve.
However, there may be an issue somewhere.
- The previous code was generating unnecessary but compliant messages. (We can always send an extra AMD.)
- I received a report yesterday that JMRI 5.1.4 gets into an infinite packet loop if there are two JMRIs on the same network.
- monitor log here: https://sites.google.com/site/balazsracz/jmri
I can not explain the infinite packet loop even in the presence of the previous code. Bob, do you have any idea?
| public int getNIDa() { | ||
| return nida.getNIDa(); | ||
| } | ||
|
|
||
| /** | ||
| * @return True of frame matches current NodeID |
|
I've never seen that AMD loop, but I only rarely have two JMRIs on the same network. Will see if I can recreate. Looking at the trace, it seems that each JMRI is somehow using multiple aliases at the same time; I don't know how that's possible. |
|
I didn't try to reproduce the issue yet, but supposedly you could start two
JMRI's and connect both to the host:port I gave you a while ago to create a
virtual network between them.
…--
Sent from my mobile device
|
|
Right. Tried that without immediate success. But there's some latency there, so if it's e.g. a problem with overlapping processing that might not provoke it. Have also put two JMRI's on a single physical network (two RR-Cirkits boards and an LCC Clock) with separate adapters, no luck. Will continue having two up while working, in case it's a rare event. |
|
You need to manually send one AMD frame to the network once both are
running.
Jmri never sends an AMD.
…--
Sent from my mobile device
|
|
OK, seen it. It's due to the problem you found in review at the top: Sending AMD in response to AMD rather than AME. Fixed by this PR. I'll put a note in the JMRI 5.1.4 "new problems" section. |
|
Did you figure out why the aliases keep changing?
…--
Sent from my mobile device
|
|
Working on it. There's also something wrong with the current version of this PR, also working on that. |
|
I was reusing the "f" frame variable, which put a local-alias AMD in it, which the rest of the processing reacted to. That's why it was cycling the alias: It thought the frame was from an external device with the same alias it had. There may still be an existing issue here with whether it's properly restarting the CIM/RIM sequence when this happens in certain states, based on reading the code, but I don't have time to make that a priority right now. |
|
I built a release with this fix, you can push it to JMRI from the usual place: https://repo.maven.apache.org/maven2/org/openlcb/openlcb/0.7.31/ |
|
Done. Thanks!
|
No description provided.