Beim Debuggen ist mir bei dem MICROCHIP APGDT002 CAN-BUS-ANALYZER aufgefallen, das die anderen Komponenten am CAN-Bus deutlich mehr Datenpakete austauschen als mit dem Analyzer aufgezeichnet werden, auch wenn es sich nur um dreimal 6 Datenpakete (1 Anfrage +5 Antworten) handelt: Bei den Antworten mit DLC = 4 gehen beim Analyzer immer die Pakete mit ID 0x81 und 0x83 verloren, das 3. und 5. Paket. Also Verlustquote 2/6 = 33,3 %. Bei DLC = 8 ist es "nur" das vierte Datenpaket, mit der ID 0x82. Also Verlustquote hier 1/6 = 16,7 %. Deshalb habe ich praktisch alle Variationen ausprobiert, aber ohne Änderung: Ohne/mit CAN-Repeater, ohne/mit Terminierung an der 0,5 m Abzweigung mit dem CAN BUS Analyzer v2.0 (d. h. mit 2/3 Terminierungen), ohne/mit Netzteil, Log Format fixed/rolling, Mode Normal/Listening only, Notebook mit Win8 64bit und Virenscanner/Notebook mit Win7 32bit und ohne Virenscanner, neuer Adapter mit USB-Firmware 2.0 und CAN-Firmware 2.3 sowie alter Adapter mit dem einzigen Unterschied CAN-Firmware 2.2. Das Ergebnis war immer gleich, der Datenverlust zu 100 % reproduzierbar. Um sicher zu sein das die Datenpaket nur bei dem Analyzer verloren gehen habe ich auch mit einem Oszilloskop nachgesehen und das zeigt mir immer jeweils 6 Datenpakete, so wie auch der Steuerrechner am CAN-Bus. Gibt es noch irgendeinen Trick mit dem man alle Datenpakete aufzeichnen könnte oder ist dieser Analyzer einfach Schrott?
Angehängte Dateien:
-
canbusanalyzer_new_2015-04-08.png
5,7 KB -
canbusanalyzer_old_2015-04-08.png
5,7 KB -
scope_0_.png
16 KB
:
Bearbeitet durch User
Vielleicht ist der Analyzer einfach zu langsam und verliert die Pakete weil er sie nicht schnell genug vom eigentlichen CAN-PIC zum USB-PIC schaufeln kann ? Wie hoch ist deine Bitrate ? (1MBit ?)
Volker SchK schrieb: > Wie hoch ist deine Bitrate ? (1MBit ?) Ja, aber schon USB 1.0 ist über zehnmal schneller. Und es werden nicht viele Bytes auf dem CAN-Bus übertragen, nur einmal alle X Sekunden 3 Anfragen und 15 Antworten (jeweils 1 Datenpaket).
:
Bearbeitet durch User
der kann keine 100% Buslast hab ich mal irgendwo bei Microchip gelesen, kauf halt was gescheites
Rolf F. schrieb: > Ja, aber schon USB 1.0 ist über zehnmal schneller. > Und es werden nicht viele Bytes auf dem CAN-Bus übertragen, nur einmal > alle X Sekunden 3 Anfragen und 15 Antworten (jeweils 1 Datenpaket). Du kannst ja mal schauen ob du die Firmware so anpassen kannst, dass die Pakete besser gepuffert werden ...
Volker SchK schrieb: > Rolf F. schrieb: >> Ja, aber schon USB 1.0 ist über zehnmal schneller. >> Und es werden nicht viele Bytes auf dem CAN-Bus übertragen, nur einmal >> alle X Sekunden 3 Anfragen und 15 Antworten (jeweils 1 Datenpaket). > > Du kannst ja mal schauen ob du die Firmware so anpassen kannst, > dass die Pakete besser gepuffert werden ... Ich brauche ein Tool zum Aufzeichnen von CAN-Daten, keines als Bastelprojekt.
Rolf F. schrieb: > Ich brauche ein Tool zum Aufzeichnen von CAN-Daten, keines als > Bastelprojekt. Warum fragst du dann nicht bei Microchip nach?
Peak-CAN USB ist die Lösung ... hat auch Software dabei zum Aufzeichnen ...
Ok, etwas von Peak scheint wohl am zuverlässigsten zu sein, aber ich probiere zunächst etwas billigeres, CANalyst-II, für um 70 Euro, auf Amazon und Ebay. Daneben frage ich mal bei Microchip nach, was die zum Datenverlust meinen.
Also mit dem CANalyst-II und dem USB_CAN Tool von CD sehe ich endlich alle CAN-Nachrichten! Von Microchip kam bisher eine Ticket-Nummer aber keine Antwort zum Datenverlust.
Rolf F. schrieb: > Volker SchK schrieb: >> Wie hoch ist deine Bitrate ? (1MBit ?) > > Ja, aber schon USB 1.0 ist über zehnmal schneller. > Und es werden nicht viele Bytes auf dem CAN-Bus übertragen, nur einmal > alle X Sekunden 3 Anfragen und 15 Antworten (jeweils 1 Datenpaket). USB 2.0 FS, falls dies hier verwendet wird, stößt nur aller 1ms einen Bulktransfer an. Solange muß man die Daten puffern. Beim Pic18 würd ich ich nicht wundern, wenn nur 1 Frame gepuffert wird, also so 64 Byte/ms.
Steffen Rose schrieb: > Beim Pic18 würd ich ich nicht wundern, wenn nur 1 Frame gepuffert wird, > also so 64 Byte/ms. Also grob gerechnet kommt man bei den meist verwendeten 1 Mbit/s auf dem CAN-Bus auf fast 125 kB/s, pro ms also 125 Byte, so das man da 50 % Datenverlust hätte. Das wäre ein grober Design-Fehler; das wäre so wie wenn am Strom-Hausanschluß nur 110 V Spannung anliegen nach dem Motto "Geht doch, Spannung ist doch da", oder ein USB-Speicherstick mit angeblich 64 GB, von denen aber alles hinter den ersten 4 MB nur write-only (Fake) ist.
Steffen Rose schrieb: > Beim Pic18 würd ich ich nicht wundern, wenn nur 1 Frame gepuffert wird, > also so 64 Byte/ms. Nach der original Beschreibung gehen doch schon Pakete verloren bevor 64 Bytes ausgeschöpft wären. Ich glaube eher, es liegt daran, dass nur einer der Empfangspuffer genutzt wird.
vloki schrieb: > Ich glaube eher, es liegt daran, dass nur einer der Empfangspuffer > genutzt wird. Gut möglich. Da der Prozessor aber nichts weiter zu tun hat, sollte er eigentlich das rechtzeitige rausholen aus dem CAN schaffen. Vielleicht gibts auch einen Engpass zw. den beiden Pics. Rolf F. schrieb: > Das wäre ein grober Design-Fehler; Schau Dir mal generell die ganzen Datenblätter der USB/CAN Interfaces an. Gerade bei den günstigen wirst du selten einen Hinweis finden, dass sie 100% Buslast bei 1MB/s garantieren. Und nichts anderes ist der Burst des TO. Anm: Wobei im allgemeinen längere Burst verkraftet werden. Die 3..4 Nachrichten sind wirklich arg wenig.
Also nach gut einem Monat kam nun eine Antwort vom Hersteller: "If you are using the APGDT002 you will not be able to see all of the CAN messages (8 per mS as per your transmission rates). Since the CANalyzer-II a different product it probably has better/faster hardware in the analyzer to parse the message data that is very fast and our hardware in the APGDT002 is unable to parse this data as fast. I am placing this ticket as resolved for now, you can correspond on it for ten more days. Resolution: APGDT002 cannot parse and display all messages whose inter message interval is < 1mS. Some message data will be lost or overwritten." Fazit: Der APGDT002 eignet sich nur für Lowspeed, bis circa 100 kBaud, jedenfalls weit weniger als 1 MBaud. Damit ist das Teil Schrott, denn die Maschinen hier verwenden meist 1 MBaud, mindestens jedeoch 500 kBaud. Das Teil geht als defekt durch Konstruktionsfehler zurück zum Versandhändler. Eigentlich müsste man noch zwei Stunden Arbeitszeit in Rechnung stellen. Neben Lowspeed gibt es nur eine andere mögliche Anwendung: Datenunterdrückung (§ 303a StGB).
Der zeitliche Abstand der Nachrichten ist entscheidend, nicht die Bitrate. Der Unterschied bei einer niedrigen Bitrate ist, dass der Abstand immer eingehalten wird. Aus diesem Grund ist die Angabe der maximal unterstützen CAN Bitrate irrelevant, wenn man die Leistungsfähigkeit eines Adapters abschätzen will.
Steffen Rose schrieb: > Aus diesem Grund ist die Angabe der maximal unterstützen CAN Bitrate > irrelevant, wenn man die Leistungsfähigkeit eines Adapters abschätzen > will. Es geht hier um Fehler, nicht Leistungsfähigkeit. Der Adapter hat Fehler die bei sehr geringen Bitraten und auch bei sehr geringen Paketraten nicht sichtbar werden.
Ich schrieb ja schon weiter oben, dass der Adapter schon extrem wenig kann. Und 100Euro für diesen Analyzer sind arg übertrieben. Insofern kann ich deine Entrüstung verstehen. Ich bleibe aber dabei, dass es je nach Preisklasse speziell bei den USB betriebenen CAN Adaptern immer eine Bitrate/Burstdauer gibt, bei der sie anfangen Nachrichten zu verlieren. Im Allgemeinen gibt es hierfür keine Angabe. Und genau hierauf bezog sich mein letzter Post.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.