Missing RTR responses

[MarkDownham]

Hi Guys,

I'm following up on a previous post:

http://www.peak-system.com/forum/viewto ... =29&t=2097

In the above, I was asking about the possibility of a MicroMod not responding to an RTR message from an angle of CANBus message "clashing". I'm happy enough with your response and it answered my question fair enough.

However, I am still trying to deal with a problem that we are experiencing where our software is sending out a burst of RTR messages when it is first initiated, but it is not reliably receiving responses from all MicroMods. This is causing our software to present incorrect status information of the sytem we are monitoring. This situation only occurs at software start-up and is always perfect once it is up and running. I've been monitoring the CANBus with PCAN-View both on the "controller" PC as well as a secondary PC which is purely listening-in on the traffic.

I was originally putting the blame on our software, but I am now wondering if it is the MicroMods that are the guilty party in this scenario; although through no fault of their own. I've gone through these forums and your help files, but I cannot seem to find the answer to the following items:

• What is the total message capacity of the MicroMods receive queue?
  What is the consequence of a receive queue on a MicroMod being full?
  And to ask a silly question: Does the receive queue get filled with all CAN messages that are flying around the CANBus network until further processed, or does the queue only get filled with messages relevant to the individual MicroMod? (my suspicion is the former, but I have to ask)

I've written a very crude program to bombard our network with RTR messages with user changeable delays between RTR messages in milliseconds. This is not a representation of our real software, but merely an extreme test bed to prove that the situation can occur. With this software I can clearly see that certain MicroMods definitely and repeatedly fail to respond when they are bombarded with my software.

Any answer you can give me to the above three questions would be highly appreciated. And please keep in mind that I am asking from the MicroMod perspective and not the PC/API point of view.

Thanks,
Mark

[G.Bohlen]

Hello Mark,

the hardware receive queue size is 3 Messages, the software receive queue size is 10 messages.
In case the software queue is full, any further messages are discarded.
Hardware or software queue overruns are internally counted. This counter is available in the configuration tool.
You can send this value on the can-bus using the tab "constant value /statistic data" and select the value type "RCV queue overrun".
Every overrun of the software queue is counted correctly, but a in case of more than one hardware overrun, only one event is counted (hardware can engine only has one flag to indicate an overrun). A hardware queue overrun is very unlikely. If you send a burst of RTR-Messages, for each missing response you should see one count in the overrun counter.
The firmware receives ALL messages from the can-bus because the hardware filter of the can-engine does not give a perfect match for all cases.

RTR request rate should not be faster than minimum 1 ms.

For a test application it is ok to send bursts of RTR to test the behaviour, but in the real application after sending a RTR it should wait for the response (or timeout) before the next RTR is transmitted.

Regards,
Gunnar Bohlen

[MarkDownham]

Hi Gunnar,

Thanks for your response; it definitely helps in trying to understand the nature of our problem.

With our “real software” we don’t send out RTRs at a faster rate than 1mS as you stated, but we do occasionally see a certain MicroMod address failing to respond. Rather strangely the address that is giving us our problem is not one of the lowest priority addresses in our system. We have tried replacing the MicroMod just in case, but the problem persists. So we are satisfied that it is not unique to a particular MicroMod unit.

With my crude application that I mentioned previously where I bombard the system with rapid RTR messages, I see a similar situation; the CAN addresses that are most affected is not necessarily the lowest priority ones.
We already knew about the “constant value/statistic data” messaging, as we use this as a “heartbeat” in our system – all MicroMods transmit this detail every second. But again, an unexpected result observed was that the MicroMods which suffered the most in failing to respond to the RTR bombardment, did not have the highest RCV Queue Error count. The most reliable MicroMods in responding to the RTRs were usually the ones with the highest RCV Queue Error count. That was not at all what I expected to see.

It’s an interesting problem, but proving a real pain in the rear to solve...

Thanks again for your response and I’ll just keep on investigating until I get a solution.

Best Regards,
Mark Downham

[G.Bohlen]

Hi Mark,

if a response for an RTR is missing it can either be because the module did not receive the RTR message (RCV queue overrun / RCV overrun) or the transmit queue was full, (XMT queue overrun). It would be worth looking for this value as well.
If this module also transmits other can-frames with a short tx-periode you could disable this can-frames for a test and check whether the number of missing rtr-responses is reduced.

Regards,
Gunnar Bohlen

[MarkDownham]

Hi Gunnar,

Looking back on the logs from my previous runs, it appears that we had no XMT Queue overruns whatsoever. Because I had two PCs running on the network, one transmitting and the other monitoring only, I can see that all RTR requests are getting out from the transmitting PC and are confirmed by the monitoring PC running PCAN-View.

Based on what you have now told me, I definitely suspect that it's the MicroMods that are failing to respond rather than the PC/software failing to catch all responses. I firmly believe that the messages are being "dropped" by the MicroMod as a result of over-flowing the receive queue and the solution is to put a little more intelligence into our PC software to ensure that this is detected (due to a lack of response) and dealt with accordingly.

Thankfully our problem only occurs occasionally when the software is started up and as far as I am aware has never occurred once the software is up and running.

Best Regards,
Mark Downham