Open m8pple opened 1 year ago
It looks to me like the logic is slightly wrong, as we have the ReadyToSend in the devices of:
That will cause either the sender
pin to fire or the SupervisorOutPin
to fire. Both of
those handlers finish with DEVICESTATE(sendMessage) = 0;
. So either a device
message is sent along the ring and one to the supervisor is lost, or vice-versa.
The supervisor has count-down logic to check that all expected messages are received, so if any messages are lost then it will hang. However, if any messages are sent to the supervisor then the token in the ring is lost, which will also cause it to hang.
I might be missing something though - is this example expected to work, or is it for documentation?
I haven't dived particularly deep into this one, but it looks like you're using an out-of-date example: orchestrator-examples
at 0b6d2d3
was from seven months ago, whereas 3a3658b
(development HEAD) is more recent.
It looks to me like the logic is slightly wrong, as we have the ReadyToSend in the devices of:
That will cause either the
sender
pin to fire or theSupervisorOutPin
to fire. Both of those handlers finish withDEVICESTATE(sendMessage) = 0;
. So either a device message is sent along the ring and one to the supervisor is lost, or vice-versa.
This is not correct - the RTS "bits" are not reset after every invocation of the ReadyToSend
logic. What happens is:
ReadyToSend
code is invoked, and the RTS bit for the sender
pin, and the RTS bit for the supervisor output pin, are both set high.sender
output pin code first [1]. The lap
field of the outbound packet is populated, and the sendMessage
field of device state is set to zero.SupervisorOutPin
code, populating the sourceId
and lap
fields of the next outbound packet, and setting the sendMessage
field of device state to zero again.@heliosfa thoughts?
I might be missing something though - is this example expected to work, or is it for documentation?
Yes, it is supposed to work ;p
[1]: Strictly speaking, the order is undefined according to the Softswitch documentation, but the order doesn't matter in this case.
If I try to run Orchestrator_examples/ring_test.xml, then it compiles and loads correctly then appears to hang.
I'm assuming (?) this should work as it is the one from the Orch_VolII documentation. I also tried
Orchestrator_examples/ping_pong_test.xml
, and that worked fine.Orchestrator version:
Orchestrator_examples: