How to gain deep knowledge of Vector CANoe to solve missed CAN messages problem ?

On Sun, 06 Dec 2015 12:30:00 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>> Sorry to be pedantic but as you know that CAN is actually only one of
>> the few protocols in which the transmitting station knows when the
>> correct signal is delivered to each receiving station terminals.
>>
>
>That's not /quite/ true.  CAN can see that the telegram has been 
>successfully transmitted to at least one other node - but you have no 
>guarantee that it is received by /all/ nodes.  

You are right, if the node is physically disconnected from the bus or
powered down, the intended receiver is not getting the message.

>It takes an unusual bad 
>bus topology to get a situation where some nodes can receive a telegram 
>correctly while others get errors, but it is possible - and may be worth 
>considering if there are lots of nodes on the bus, or it is poorly 
>terminated, or laid out in something other than a linear bus.

Each node checks the CRC for each telegram and if it detects a CRC
error, it should garble the bus and every node (including the
transmitter) on the bus should detect this garbling. 

Of course, lots of garbled messages will finally kill the throughput
and cause unacceptable latencies.

I have worked with CanOpen systems with 50-75 nodes, 100-250 m cable
lengths, carefully observing branch cable limitations and optoisolator
delays. Sometimes it works reliably on the calculated speed, sometimes
we had to drop the line speed.  

>Also note that all CAN controllers on the bus will send an acknowledge 
>bit if the telegram is seen in the correct format, with the correct CRC 
>check - it says nothing about the CAN controller being set up correctly 
>to receive the message.

The Ack bit tells the transmitter that it is connected to at least one
other node. Garbling/jamming tells that at least on node on the net is
"hard of hearing".

On Fri, 04 Dec 2015 15:21:07 -0600, "learn" <102059@EmbeddedRelated>
wrote:

>Our Electronic Control Unit (ECU) is based on Renesas RH850F1L
>Microcontroller.  We basically have closed loop control system.  
>
> Outputs of this ECU power DC Motors to move Third-Row Minivan Seats.  
>
> ECU inputs are coming from DC Motor.  This feedback signal is hall pulses
>indicating whether motor is turning or not or whether seat is moving or
>not.
>
> The software running in the ECU talks to PC Based CAN tool.  They talk
>over simple proprietary protocol.  They basically talk over 11-bit CAN.
>
> When the seat is moving, every 10ms, software running in the ECU sends
>seat position message to PC Based CAN Tool.  When seat is at position 1,
>position 1 message is sent to the tool.  After 10ms, position 2 message is
>sent to the tool. After next 10ms, position 3 message is sent to the tool,
>and so on.  
>
> If everything is working correctly, over 1000 consecutive position
>messages will be sent to the tool.  Time between these messages will be
>about 10ms.  
>
> The problem is that from time to time messages are getting missed.  The
>message that don't make it to the tool also don't show up in the CAN log.
>
> First 80 position CAN messages are correctly sent by ECU and correctly
>received by the tool.
> Position messages 81 through 84 don't show up in the tool.  Also, they
>don't show up in the CAN log.

What is "position", is it just a serial number or a CAN identifiers
(which determines the telegram priority) ?

Have you calculated the buss throughput at your chosen speed with
maximum payload and maximum transparencies (worst case about 150 bits
in a telegram) ? 

How long is your transmission queue, does it overflow when a lot of
messages are sent in a burst ? Do you have a priority (CAN-ID) based
transmit queue system ? 

What is your transmit timeout ? Can a message be deleted, before it is
actually transmitted due to low priority ?
 

On Sun, 6 Dec 2015 13:41:51 +0100, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>Am 05.12.2015 um 23:00 schrieb upsidedown@downunder.com:
>> On Fri, 4 Dec 2015 23:44:03 +0100, Hans-Bernhard Br&#4294967295;ker
>> <HBBroeker@t-online.de> wrote:
>
>>>>    The problem is that from time to time messages are getting missed.  The
>>>> message that don't make it to the tool also don't show up in the CAN log.
>>
>> The problem with the OP's case seems to be that the messages are lost
>> somewhere between the receiver station terminal and the final
>> application.
>
>I don't think so.  If they had gotten lost inside the receiver, they 
>would at least have shown up in the CAN log, which I'm assuming is made 
>by CANoe, separate from the receiver itself.

After rereading the original message, I agree with you.

The problem is too systematic to be attributed to some electrical
problems on the network.

Of course having a monitoring device separate from the CANoe would be
helpful.

It more sounds like an overload problem on the transmission side, too
much or too long data bursts into the buss compared to average
throughput would also explain the lost messages.

>>> CAN, like any multi-master shared-medium protocol, cannot guarantee
>>> successful delivery of every single message.
>
>> Sorry to be pedantic but as you know that CAN is actually only one of
>> the few protocols in which the transmitting station knows when the
>> correct signal is delivered to each receiving station terminals.
>
>Except that it doesn't, for at least two reasons:
>
>1) The CAN ACKknowledge field is essentially a wired OR, i.e. the 
>transmitter gets a successful ACK if any other active node saw a 
>correctly formed message --- there's no requirement for every node to 
>agree on that.
>
>2) ACK does not depend on actual delivery of the received message.  Even 
>if a message is blocked by a node's input filters, it will still be 
>ACKed by that node.

That might explain why some specific messages are always lost if
"position" refers to the CAN identifier.

Hans-Bernhard Br�ker wrote:
> Am 05.12.2015 um 21:03 schrieb Les Cargill:
>> Tauno Voipio wrote:
>
>>> CAN is a broadcast datagram protocol. It in the nature of such
>>> protocols that messages occasionally get lost. Even UDP in the
>>> TCP/IP protocol suite has to accept lost datagrams, although
>>> it does not always use broadcast addressing.
>
>> The addressing in CAN is about what's in the PDU, not where it's going
>> or who it's from.
>
> It has to imply who it's from, if only because otherwise there would be
> unresolved collisions between two nodes sending messages bearing the
> same ID, and starting simultaneously.
>


Nicht, nicht, das is verboten! :) ( for the reason you say )

With CAN, you must have seperate media for two devices transmitting
with the same CAN id. There can be only one...

I suppose there is some way in which to be clever about it, but it's
an indefensible sort of cleverness.

-- 
Les Cargill

Hans-Bernhard Br�ker wrote:
>>> In a nutshell: this test run has exposed a flaw in your proprietary
>>> little protocol.  You need to repair that flaw, not the test run.
>
>> How to find out what is ill suited about our protocol?
>
> I already told you that: it's the fact that it appears to assume that
> every single message will successfully make it onto the bus.  That
> assumption has turned out to be incorrect.
>
>> And then how can we make it robust so messages aren't missed.
>
> The point I was explaining to you is that you _can't_ make messages not
> be missed.  You'll have to build a protocol that can withstand missed
> messages to some extent, or at least notice that messages didn't arrive.


No protocol makes messages that cannot be missed.

-- 
Les Cargill

Il giorno venerd� 4 dicembre 2015 22:21:13 UTC+1, learn ha scritto:
 
>  The problem is that from time to time messages are getting missed.  The
> message that don't make it to the tool also don't show up in the CAN log.

so the messages don't go through the bus OR the tool/log can't read them for some reason?

> 
>  I'm using very complex CANoe Configuration File that was created by
> someone else.  It's overwhelming.  There are so many nodes, so many
> message in CAN Trace.  

you can filter only the messages you want (ie. with the good ID), RTFM to know how to do that (Hint: add filter block on the Measurement Setup).
you can also create your own config file, or ask the guy who did it for some help.

>  From where do I begin to debug this problem. 

It's the ECU that is not sending messages or the PC that don't visualize them?
Connect a oscilloscope to the bus and find out.

>  11-bit proprietary protocol messages are exchanged between ECU and tool. 
> Also, CANoe is sending so many  messages.  I don't even know what all
> these messages are.  I have a hint as follows:
> 
>  Hint:  CANoe sends messages to ECU in bursts.  Instead, it needs to send
> them at slower rate.  This might be the reason low priority position
> messages are missed from ECu.  Turn off some nodes in CANoe.  
>  This shouldn't be ECU software problem because it's not sending messages
> in bursts.
> 
>  This is challenging problem for me because I don't have sufficient CANoe
> knowledge.  Please help debug this problem. 

The only way to get sufficient knowledge is to RTFM.