CAN bus errors

#4

You are saying you are receiving all messages correctly but there event is not fired, correct? If you loop and read will you have any problems?

1 Like
#5

Did you try in a loop? I was told that we see planning on redoing CAN in next preview so it wouldn’t make sense to try to fix now and change in 2 weeks.

#6

It does appear to be stress related. When I receive multiple packets for a request, the event for the last packet does not happen. I slowed down the rate of making requests and that helped reduce the missing events. I also tried reducing how often I refresh the screen which helps also. However, the missing events still happen.

#7

So there are no missing messages? You are selling all messages but sometimes you have messages pending but no events?

#8

Might be useful to post the read code in the message received handler.

#9

Not remember exactly but ~1500-2000 events in a second is OK. More than that may lost, even with Gpio Interrupt. If event is complex then may less.

#10

Is there a fix in Preview 6. I didn’t see any reference to this issue in release notes

#11

As mentioned earlier, we are adding CAN FD next release so it wouldn’t make sense to do any work in this one.

Your way did not answer our question on missing messages if you are not using events. The more info you provide the faster we can help.

#12

Lost message and lost event are different.

So try to poll if more than 1000 msg /sec, or just count message in event, use other thread to read msg.

If parse ID, DateTime, Data, WriteLine…… all in the event then I don’t think it can handle fast enough. The example code we provided in doc just an example for simple case.

#13

I will move as much as I can to foreground thread and do only data collection on receive event. Hope it works.

#14

Please let us know. It makes a big difference if the problem is in missing messages or missing events.

#15

I think it is missing events. After I recover from the missing event, I send another request. On the subsequent message received event the data read is the remainder of the previous request. The next event is from the previous message, and so on.

#16

Can you for now then rely on continuous reading? CAN is right on the top of the list.

Any other feedback is appreciated as we are redoing CAN altogether.

#17

There are a couple things I will try. Let you know what happens.

1 Like
#18

Put only saving of received data in messagereceived event. Put all parsing and processing of content in foreground thread. Still missing an event

1 Like
#19

How heavy send / receive in your system?

#20

In normal operation, it will send 25-35 messages (requests) per second. Many of the responses are more than 8 bytes so will receive multiple messages per request

I have successfully implemented a work around where I ignore message_received events and continuously poll for data. The poll for read ends:

  1. at the receipt of the end-of-message flag in the data
    or
  2. timeout
#21

I don’t think 25-35 msg / sec cause lost event. It is not much. Is there any other event in your project, beside CAN receive event?

For poll receiving, something like this:

private static void PollReceiving() {
    while(true) {
        if (canController.MessagesToRead > 0) {
           // Read
           var length = canController.MessagesToRead;
           var msgs = new GHIElectronics.TinyCLR.Devices.Can.CanMessage[length];
           canController.ReadMessages(msgs, 0, msgs.Length);

           ….

        }
    }
}
static void Main() {
   /// setup CAN

   new Thread(PollReceiving).Start();
}
#22

I have already implemented the poll receiving. It is working great and I am able to receive any length message.

2 Likes
#23

Ok great this is very helpful