[John Heden]

Greetings,

Thanks for the reply and discussion. We have a relatively small error rate of approximately 1 timeout every 3 or 4 seconds or about 1/4000 transactions.

While I suspect these occasional timeouts are harmless given our use (the next output is never more than 20 ms away), I would like to understand what is causing these with some frequency as I suspect (graciously) there may be a possible multithreading vulnerability in the system (our code, WPIlib, 2CAN, Jaguar, or elsewhere). We would prefer zero CAN timeout errors on the system if possible and would like to understand any limitations and expectations in full detail.

There have also been some debate within the team as to whether too many JAG transactions/sec can actually cause these timeouts. I have heard this bus overload theory from other teams as well and would like to separate fact from fiction on this front.

Of course, the S/W stack is not ideal and you have to respect any constraints the Jaguar has in terms of handling overlapping commands.

I wonder how often the Jags ever get overlapping commands, if ever, under normal use. Any single thread execution is essentially serialized nicely with each send/receive (ack) transaction.

Then I'd check to see if your thread scheme is fighting with the serialization that happens to commands. If you issue a bunch of commands and they wind up being serialized

The basic WPIlib seems to implement a simple blocking call waiting for a response of ack to each command. Introduce another thread and we still have each thread running synchronously through each of its its programmed transactions. The two threads will hit the CanJaguar m_transactionSemaphore only if they happen to hit the same Jaguar instance with no serialization across Jaguars at all. Given the relatively quick responsiveness of each Jag transaction (~200us for entire call) there is rarely any simultaneous Jag transactions but this is still expected to occur occasionally. Given this infrequent very infrequent command overlap, I suspect that ensuring complete (inter or intra jag) serialization with a jaguar wide semaphore will have no noticeable performance degradation (an occasional rare brief thread suspension). I'll try this experiment and see whether it reduces or eliminates our occasional error.

Really, you want an async interface where nothing gets serialized except on the actual transmission of messages out onto the bus

I'm curious as to where this low level serialization is ensured ? Is it in the 2CAN ?

Thanks again,

john