Implement Transport Layer Connection-Oriented State Machine Style 3

[dallmair]

Implement Transport Layer Connection-Oriented State Machine Style 3

[bmalinowsky]

TP1 uses CSMA/CA, how would the partial frame after a detected collision manifest itself? The tx stops sending.

The relevant part for the TL stuff of vol. 6 "profiles" is chapter 9, mgmt client, not chapter 6. There (v2.1, sec. 9.2.3.3) it specifies TL-CO style 1. Style 3 would be for the server part, but that is not active when used as client.

[dallmair]

Many thanks for your fast response!

Well, I see my description above was pretty hand-wavy, sorry about that. Although it does not really matter due to your absolutely correct answer, I'd like to record what we're seeing so we don't need to go through this exercise again.

TP1 uses CSMA/CA, how would the partial frame after a detected collision manifest itself? The tx stops sending.

In general, it depends on the timing of the spike/collision, of course. However, the IP interface in the production installation we're seeing this in ignores these spikes and continues sending.

The full picture is that there are some other devices that respond with LL_NACK or LL_BUSY. Our DIY devices did not send LL_BUSY in the (distant) past and do not send it as of today, so it must be some certified device which responds with NACK/BUSY although it is not even being addressed. With more than 40 devices on the bus, it's kinda hard to identify the culprit, though.

So the flow of events as we understand it is:

1. IP interface sends LOW priority telegram that is part of point-to-point connection-oriented communication.
2. Our DIY device receives the telegram successfully (all parity bits and checksum are ok), sends an LL_ACK and processes the telegram.
3. At least one other device has severe issues to distinguish between spikes and bits and for whatever reason responds with LL_NACK or LL_BUSY.
4. Some HIGH priority telegram gets sent on the bus.
5. IP interface repeats the LOW priority telegram from step 1. Our DIY device sees same telegram again. Due to the telegram from step 4, the repetition is not filtered out by the Data Link Layer and forwarded up to the Transport Layer, where things go downhill if Style 3 is not implemented, i.e. the connection goes down.

The relevant part for the TL stuff of vol. 6 "profiles" is chapter 9, mgmt client, not chapter 6. There (v2.1, sec. 9.2.3.3) it specifies TL-CO style 1.

Ouch, you're right. Heads down analyzing the issue I totally forgot that this is about the Management Client and mixed things up. Sorry! --> Issue closed.