Troubleshooting

The signal is written, but the packet never goes out

1. Is the packet group started? After start-up every group is stopped. A write to a stopped packet is stored, the call answers "not available", and nothing is sent. Look at ComIPduGroupRef of the packet and at who starts that group.
2. Is the signal pending in a packet without a timer? ComTransferProperty = PENDING with ComTxModeMode = DIRECT means nothing ever asks for a send.
3. Is the active send setting NONE? Either it is set that way, or the packet is on its "false" setting and ComTxModeFalse says NONE.
4. Is the signal "on change" and the value did not change? COM compares with the value sent last, or with the start value if nothing was sent yet.
5. Is the signal a member of a signal group? Writing a member only fills the staging area. The application must hand over the whole group.
6. Does the send heartbeat run? Sends happen in Com_MainFunctionTx. With several heartbeats, ComIPduMainFunctionRef says which one serves the packet.
7. Does COM hand the packet down, but the bus stays silent? Then the problem is below COM, in the route of the packet. See lesson 14.

Lesson 2, lesson 11

The packet goes out later than expected

1. The heartbeat. A triggered send happens at the next send heartbeat at the latest, not inside the write. Look at ComMainTxTimeBase.
2. The minimum gap. A send asked for during the gap waits until it is over. Look at ComMinimumDelayTime.
3. The start delay. The first timer send after the packet was started waits for ComTxModeTimeOffset.
4. Is only the "sent" message late? With ComIPduSignalProcessing = DEFERRED the message comes at the next heartbeat. The packet itself was on time.

Lesson 3

The packet goes out too often

1. Triggered on every write. TRIGGERED sends even when the same value is written again. TRIGGERED_ON_CHANGE does not.
2. Repeats. ComTxModeNumberOfRepetitions is the number of extra sends. 2 means three packets per write.
3. Timer and trigger together. MIXED sends on the timer and on every triggered write.
4. Switching the send setting. A switch to the other setting sends the packet at once, unless that setting is NONE.
5. No minimum gap. ComMinimumDelayTime left out or 0 means no limit on how close two sends can be.

Lesson 3, lesson 4

Fewer repeats on the bus than configured

1. A new write came in between. It cancels the repeats that are still open and starts the count again.
2. The signal is "without repetition". TRIGGERED_WITHOUT_REPETITION and TRIGGERED_ON_CHANGE_WITHOUT_REPETITION send once, whatever the packet says.
3. A timer send was counted. In MIXED, a timer send that falls into the repeats counts as one of them.
4. The send timeout struck. When ComTimeout runs out before all repeats are done, the rest is dropped.
5. The other send setting is active. The "true" and the "false" setting each have their own number of repeats.

Lesson 3

The timer period on the bus is wrong

1. Seconds, not milliseconds. ComTxModeTimePeriod = 0.1 is 100 ms. A value of 100 is 100 seconds.
2. Which send setting is active? The "true" and the "false" setting can have different periods.
3. Does the heartbeat really run as configured? COM counts time in heartbeats. If ComMainTxTimeBase says 10 ms but the function is called every 20 ms, every period doubles.
4. Is the period a multiple of the heartbeat? If not, it gets rounded.
5. Is the minimum gap longer than the period? Then the gap decides, unless ComEnableMDTForCyclicTransmission is false.

Lesson 2

The packet uses the wrong one of its two send settings

1. Which signals have a condition? Every signal of the packet with a ComFilter box takes part. All others do not.
2. One true is enough. The "true" setting is used as soon as one condition is true. "False" needs all of them false.
3. A condition ALWAYS. It is always true, so the packet never leaves the "true" setting.
4. No condition at all. Then the result is always "true" and ComTxModeFalse is never used.
5. Right after the start. Until the application writes, the conditions are checked with the start values.

Lesson 4

"Not sent in time" is reported although the bus looks fine

1. Does the bus confirm sends? Without confirmations from below the send timeout always strikes.
2. Is the limit shorter than the repeats take? With repeats, the send only counts as done after all of them were confirmed.
3. Another signal's limit. If signals of one packet have different ComTimeout values, the shortest one is used for the packet.
4. Expecting it more than once? The message is given once per failed send and not repeated.
5. Was the packet stopped? Then the open send is reported as "could not be sent" instead.

Lesson 6, lesson 9

The packet arrives, but the application is never told

1. Is the packet group started? A stopped packet is ignored when it arrives.
2. Is a "new value" message set? It lives in the set-up of COM's user, as a ComUserCallback of type COM_RX_ACK, and the signal must be linked to it. In older projects: ComNotification on the signal.
3. Deferred, and the receive heartbeat does not run? With ComIPduSignalProcessing = DEFERRED the message is given in Com_MainFunctionRx.
4. An update-bit that is never set. If ComUpdateBitPosition is configured here but the sender does not set that bit, or uses another position, the signal is ignored.
5. A filter that blocks. A blocked value is thrown away without a message. Look at ComFilter of the signal.
6. The invalid value. With ComDataInvalidAction = NOTIFY, the reserved value gives only the "invalid" message.
7. The packet is shorter than expected. Only signals that are completely inside the received bytes are unpacked.
8. The signal is a member of a signal group. Messages exist for the group only.

Lesson 9, lesson 5, lesson 8

The application always reads the start value

1. Go through "the application is never told" above. A stopped packet, an unset update-bit or a blocking filter all leave the start value in place.
2. A member of a signal group. The application must first fetch the whole group. Only then do the members hold new values.
3. Read too early. With DEFERRED, a read between arrival and the next heartbeat still gives the old value.
4. A timeout puts it back. ComRxDataTimeoutAction = REPLACE returns to the start value each time the limit runs out.

Lesson 5, lesson 10

Nothing arrives, but no timeout is reported

1. Is there a time limit? ComTimeout left out or 0 means the signal is not watched.
2. Did anything ever arrive? Without ComFirstTimeout, watching only begins after the first arrival.
3. Is an "overdue" message set? A ComUserCallback of type COM_RX_TOUT, linked to the signal. Without it, only the value may change.
4. Is the packet group started? A stopped packet is not watched.
5. Was watching switched off? It can be switched off and on per packet group while running, with Com_DisableReceptionDM and Com_EnableReceptionDM.

Lesson 6

A timeout is reported right after the start

1. The first limit is too short. ComFirstTimeout must cover the time the sender needs to start, plus its start delay and one period.
2. The group is started too early. The stopwatch starts when the packet group is started. If that happens before the bus is up, time is lost.

Lesson 6

The timeout is reported again and again

1. This is how it works. On the receiving side the stopwatch restarts when it runs out. The message comes after every further ComTimeout as long as nothing arrives. Only the send timeout is reported once.

Lesson 6

A timeout is reported although the packet arrives

1. The signal has an update-bit. Then it has its own stopwatch, and only packets with the bit set count. A sender that sends the packet but does not write the signal causes a timeout.
2. Another signal's limit. Signals without update-bit share one stopwatch per packet. It uses the shortest limit of all of them, including ComFirstTimeout values.
3. The limit is too close to the sender's period. One late frame is then enough. Seconds, not milliseconds: 0.3 is 300 ms.
4. The heartbeat. COM counts time in heartbeats. A limit that is not a multiple gets rounded.

Lesson 6, lesson 5

The value jumps back to the start value

1. Timeout with replace. ComRxDataTimeoutAction = REPLACE.
2. Invalid value with replace. ComDataInvalidAction = REPLACE hands out the start value whenever the reserved value arrives.
3. The packet group was started again. Starting a group with "initialize" puts all its signals back to their start values.

Lesson 6, lesson 7

The "changed" filter lets an unchanged value through

1. After a timeout. The first value after a timeout always passes MASKED_NEW_DIFFERS_MASKED_OLD.
2. The mask. Only the bits set in ComFilterMask are compared. A change in other bits is not seen, and the other way round.
3. Compared with what? With the last value that passed, not with the last value that arrived.

Lesson 8

The receiver sees a wrong value

1. Byte order. ComSignalEndianness must be the same on both sides. Swapped bytes are the typical sign: 0x1234 arrives as 0x3412.
2. Start bit. ComBitPosition is the lowest bit of the signal for LITTLE_ENDIAN and the highest for BIG_ENDIAN. Other tools and file formats count differently.
3. Size. ComBitSize must match on both sides.
4. Overlap. Two signals, or a signal and an update-bit, on the same bits.
5. Both sides wrong in the same way? Compare each side with the network description, not with each other.

Lesson 16, signal packing sheet

A negative value arrives as a large positive one

1. The type. ComSignalType must be a signed type (SINT8 to SINT64) on the receiving side. Only then does COM fill up the upper bits correctly.
2. The size. With a wrong ComBitSize the sign bit is taken from the wrong place.

Lesson 17

Only some of the sent values reach the application

1. A filter. ONE_EVERY_N passes one value in N. A range or mask filter passes only matching values.
2. An update-bit. Packets in which the sender did not write the signal are ignored for this signal.
3. Several arrivals per heartbeat. With DEFERRED, values that arrive faster than the receive heartbeat can be overwritten before the application is told.

Lesson 8

A forwarded signal does not appear on the other bus

1. Does the gateway heartbeat run? Copies are made in Com_MainFunctionRouteSignals. The packets involved point to it with ComMainFunctionRouteSignalsRef.
2. The source has an update-bit that is not set. Then nothing is forwarded.
3. The outgoing packet is stopped. Its packet group must be started too.
4. The destination signal is pending and its packet has no timer. The value is copied but nothing sends it.
5. A packet that is sent in pieces. Signals of packets with ComIPduType = TP cannot be forwarded.

Lesson 12

A forwarded signal is late

1. Three waits add up. The gateway heartbeat (ComMainRouteSignalsTimeBase), then the send heartbeat, then a minimum gap of the outgoing packet if one is running.
2. The destination is pending. Then the value waits for the next timer send of its packet.

Lesson 12

The configuration tool rejects the settings

These are the rules of the specification that are broken most easily.

1. Update-bit together with repeats. Not allowed in one packet.
2. A sending packet without ComTxIPdu, or with neither ComTxModeTrue nor ComTxModeFalse in it.
3. Overlapping signals in one packet.
4. ComBitSize larger than the type, for example 12 bits in a UINT8.
5. A row of bytes that does not start on a byte border, or whose byte order is not OPAQUE.
6. A filter the type does not support. Decimal numbers and rows of bytes: only ALWAYS, NEVER, ONE_EVERY_N. On/off values: no range filters.
7. ONE_EVERY_N with ComFilterOffset not smaller than ComFilterPeriod.
8. An invalid value without an action on a received signal.
9. A packet group with both directions. All packets of one group must be sending, or all receiving.
10. Names. Two of the names of signals, groups, members, packets and packet groups are the same, or one is not a valid C name.
11. A signal of changing length that is not the last one in its packet, or a second one in the same packet.
12. Forwarding between signals of different bit size.

The configurator checks most of these for a single signal.