search

openlcb / documents

The OpenLCB specification: standards, recommended practices and other documentation.
3 stars 7 forks source link

Multiple CAN Multi-Frame Messages In Flight Clarification #9

Closed bakerstu closed 1 year ago

bakerstu commented 6 years ago

Summary

In my recent discussions with Balazs, it became clear that we both had different interpretations about Multi-Frame CAN messages, and whether there can be multiples of these in flight between the same two nodes, but with different MTIs.

I believed that there could not, Balazs believed so. In a closer inspection of the Standard and TN, it seems that this is not specified or discussed in detail. After further discussion with Balazs, we came to the conclusion that Balazs' interpretation must be correct, because if it were not, there could be a priority inversion on the bus. Avoiding these priority inversions is paramount in having a bounded buffer size required for receiving nodes.

Here is one scenario using my interpretation (priorities are made up, lowest number = highest priority):

Node A request send Multi-Frame message to Node B, priority 3 Node A request send Multi-Frame message to Node B, priority 1 Node C request send message, priority 2

The result on the bus could be:

Node A sends first frame of Multi-Frame message to Node B, priority 3 Node C sends message priority 2 Node A sends last frame of Multi-Frame message to Node B, priority 3 Node A sends first frame of Multi-Frame message to Node B, priority 1 Node A sends last frame of Multi-Frame message to Node B, priority 1

Using Balazs' logic, which is proposed to be correct, the result on the bus would be:

Node A sends first frame of Multi-Frame message to Node B, priority 3 Node A sends first frame of Multi-Frame message to Node B, priority 1 Node A sends last frame of Multi-Frame message to Node B, priority 1 Node C sends message priority 2 Node A sends last frame of Multi-Frame message to Node B, priority 3

Note the difference in bold.

One obvious issue that could arise is a nodes' inability to buffer more than one multi-frame message at a time. The standard already provides a means for the receiving node to drop a multi-frame message and report back to the sender with a temporary error.

Conclusion

The task proposed by this issue is to clarify the Standard and/or TN to require Balazs' logic.

balazsracz commented 1 year ago

This does not touch the CAN Frame transfer standard, because that standard only describes the CAN-specific control frames. The generic OpenLCB messages (with an MTI) are in the MessageNetworkS in the CAN section.