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

Am 04.12.2015 um 22:21 schrieb learn:

If that poses a serious problem to your usage of those data, that means that proprietary protocol of yours is ill-suited for use over CAN.

CAN, like any multi-master shared-medium protocol, cannot guarantee successful delivery of every single message. That means protocols that are run across it must be able to tolerate the occasional missed message, and either request a re-transmission, or just cope with not having that particular packet at all.

So, given you a) neither know nor care what all those message are for, and b) you're only interested in those few message of your own protocol, why are you even using that big simulation? I'll assume you do that because the real work environment of your ECU has all those nodes, too, sending just as many messages. So turning off some of the simulated nodes is not going to actually solve anything. It'll just make the simulation lose some similarity to the real environment.

Unless you have some way of guaranteeing that similar message burst patterns cannot ever happen in real life, with multiple real ECUs on the bus instead of a single CANoe simulating them all, your problem is _not_ how to keep CANoe from producing those message bursts --- it's how to keep your protocol from breaking apart if they do happen.

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.

The

log.

Thank you for steering us in the correct direction.

How to find out what is ill suited about our protocol? And then how can we make it robust so messages aren't missed.

What source(s) will provide me more information on lack of CAN robustness (missed messages can occur)?

Yes, I'm using complex CAN configuration because it simulates real world environment.

--------------------------------------- Posted through

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.

--

-TV

The addressing in CAN is about what's in the PDU, not where it's going or who it's from.

--
Les Cargill

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.

That is the real issue.

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.

The other question is can that signal be transferred to the application.

As I have said many times regarding real time control systems:

1.) you can have some time specific unreliable information transfer (e.g. UDP) 2.) you can have reliable connections but no real time predictability (e.g.. TCP)

There is no "correct" solution, but you have to select case by case what to use.

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. 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.

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.

Indeed.

Yes.

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.

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.

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.

Am 05.12.2015 um 23:00 schrieb snipped-for-privacy@downunder.com:

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.

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.

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

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.

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".

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 ?

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.

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

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

No protocol makes messages that cannot be missed.

--
Les Cargill

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

you can filter only the messages you want (ie. with the good ID), RTFM to k now 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 som e help.

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

The only way to get sufficient knowledge is to RTFM.