Doc: Actually, I want to thank you for making me pull out my documents and review some specifications which apply to CAN 2.0 part B and J1939 in particular. Between this thread and the "USB-8473 BusMonitor Error Frame" thread several questions were raised that I believe are answered by a close examination of the CAN 2.0 part B specification dated September 1991, available for download at http://www.semiconductors.bosch.de/pdf/can2spec.pdf. I was looking through the J1939 specifications, specifically J1939-11 "Physical Layer" and J1939-21 "Data Link Layer" when Section 5.8 of the latter ("Error Detection") pointed me to the previously referenced document. In the Can 2.0 part B specification in section 3.1.3 "ERROR FRAME" in the first paragraph I found and here excerpt a portion for everyone's edification: "In order to terminate an ERROR FRAME correctly, an ’error passive’ node may need the bus to be ’bus idle’ for at least 3 bit times (if there is a local error at an ’error passive’ receiver). Therefore the bus should not be loaded to 100%."
I cannot say with authority that there isn't anything else within either that document or the voluminous J1939 specifications referring to bus loading or error frames, but it does seem to answer the two question threads. I would say based on that section that if a J1939 network is physically perfect, and if the controller applications on that network are also perfect, that bus loads approaching 100% should be easily attainable and quite reliable if everybody on the network plays nice together. I have done it with less than perfect networks and operated for days without errors at 95% bus loads using the XNET hardware and LabVIEW real time. I believe the reason the XNET hardware works so well is it makes better informed use of the TXObject buffers available and handling of multiple queued objects (frames or packets, whichever terminology you prefer) being mindful of the reception order and artbitration values of the queued frames .
On the subject of Error Frames I believe the problem turned out to be a faulty controller, but a close look at section 3.1.3 of the CAN part B specification is pretty definitive in describing the cryptic messaging of error frames, since Bosch wrote the book on it 
.
