Bei USB-CAN-Adaptern, z. B. dem MICROCHIP CAN BUS Analyzer (der bei Datenpaketen innerhalb 1 ms um 50 % der Daten verliert/nicht anzeigt) und dem Canalyst-II (kein Datenverlust) hat man ja schon durch das USB-Framing eine Auflösung von theoretisch bestenfalls 1 ms, und praktisch zeigen sich mehr als 10 ms. Das heißt alles was in 10 ms eingeht wird als gleichzeitig angezeigt, von Programmen wie CANalyzer oder USB_CAN Tool. Das ist ungenügend, wenn man in einer Millisekunde 10 oder mehr Datenpakete hat und die nicht nur mit dem Oszilloskop zeitlich separat sehen möchte. Deshalb suche ich Adapter mit denen es das Problem nicht gibt. Können PCI- oder PCIe-CAN-Karten das, also zumindest auf 10 bis maximal 100 Mikrosekunden genau die Zeiten der Datenpakete angeben? Bei einfachen Ports wie Parallelport oder serieller Schnittstelle, onboard oder per PCI(e)-Karte, sehe ich nur eine Latenz von maximal 2 Mikrosekunden. Also sollte das auch mit CAN-Adaptern gehen, aber ein Adapter kann ja lange zwischenpuffern und auch der Treiber kann lange zwischenpuffern. Und die Hersteller schweigen ja zur Latenz.
In der Regel hat jedes CAN-Paket auch einen Timestamp. Die Firmware wird diesen aber wohl nicht mit ausgeben.
Gast
#4199318
Das ist nicht das Problem des USB, sondern ein Problem der Softwarearchitektur. Wenn der CAN-to_USB-Adapter selbstständig die Zeitstempel erzeugt und zusammen mit den CAN-Daten an den PC weiterleitet, dann kannst Du fast beliebige Latenzen auf der USB-Übertragung haben und trotzdem eine korrekte Anzeige bekommen. Gruß, Stefan
Und im Gegensatz dazu kann es bei passiven CAN PCI Karten passieren, dass die Zeitstempel erst "sehr spät" durch das OS erzeugt werden. Wenn ich mich recht erinnere, haben die USB Interfaces von EMS Wünsche eine hohe Auflösung und Genauigkeit. Am besten explizit wegen der Genauigkeit nachfragen. http://www.ems-wuensche.de/product/datasheet/html/can-usb-adapter-converter-interface-cpcusb.html Dass Vector gute Interfaces hat, sollte bekannt sein.
Gast
#4199356
Also bei den Vector Produkten gibt es meines wissens einen Hardware Zeitstempel. Ich hab nur mit 10ms Intervall bei 15 Knoten was gemacht, das ging problemlos. Und wie viele Kommastellen der Zeitstempel hat kann ich dir nicht genau sagen, bzw müsste ich später nach schauen. Aber ich denke der Support von Vector kann dir da weiter helfen. Ich gehe mal davon aus, dass bei 100% Buslast bei 1 MBaud kein Verlust sein sollte.
Stefan schrieb: > Wenn der CAN-to_USB-Adapter selbstständig die > Zeitstempel erzeugt und zusammen mit den CAN-Daten an den PC > weiterleitet, dann kannst Du fast beliebige Latenzen auf der > USB-Übertragung haben und trotzdem eine korrekte Anzeige bekommen. Ja, nur gibt es die in der Praxis nicht, also CAN-to_USB-Adapter die selbstständig Zeitstempel erzeugen. Zumindest MICROCHIP CAN BUS Analyzer und Canalyst-II arbeiten nicht so oder sie haben über 10 ms Zeitauflösung.
Rolf F. schrieb: > also CAN-to_USB-Adapter die > selbstständig Zeitstempel erzeugen Zumindest haben viele CAN-Controller einen Timer, dessen Wert in jedem MOB mit gespeichert wird, dagegen kannst Du nichts machen. Nur muß die Firmware diesen Wert auch über USB mit übertragen. Und dann muß das PC-Programm ihn mit anzeigen.
Gast
#4199381
Ich danke es kommt darauf an, wieviel Funktionalität im CAN-Adapter steckt und wieviel vom PC erledigt werden muss. Wenn ich mich recht erinnere lag die minimale Intervallzeit der Windows-Timer bei 10ms, die der hochauflösenden Timer bei 1ms. Mit einer PC-Lösung kommst du da also nicht weiter, es sei denn, der CAN-Adapter erledigt selbstständig PC-unabhängig die zeitkritischen Aufgaben. Grundsätzlich kann man also sicher sagen, die billigsten CAN-Adapter werden Deinen Ansprüchen nicht genügen. Eine gute Empfehlung ist es, wie oben schon geschrieben wurde, lass dich vom Vertrieb von Vector beraten. Dort gibt es CAN-Adapter unterschiedlicher Preisklassen.
Gast
#4199388
Alternativ könnte man natürlich auch noch über eine aktive CAN PCI-Karte nachdenken.
Steffen R. schrieb: > Wenn ich mich recht erinnere, haben die USB Interfaces von EMS Wünsche > eine hohe Auflösung und Genauigkeit. Am besten explizit wegen der > Genauigkeit nachfragen. ich benutze hier auch einen Adapter von EMS Wünsche und zeichne damit CANopen Kommunikation bei einer Baudrate von ~1Mbit/s auf.
Steffen R. schrieb: > Und im Gegensatz dazu kann es bei passiven CAN PCI Karten passieren, > dass die Zeitstempel erst "sehr spät" durch das OS erzeugt werden. Das ist kein Problem, denn die Verzögerung liegt bei unter zwei Mikrosekunden, für die Datenübertragung von der Karte zur CPU. So mache ich Zeitstempel für passive Karten wie eine Paralleportkarte. > Wenn ich mich recht erinnere, haben die USB Interfaces von EMS Wünsche > eine hohe Auflösung und Genauigkeit. Am besten explizit wegen der > Genauigkeit nachfragen. > > http://www.ems-wuensche.de/product/datasheet/html/can-usb-adapter-converter-interface-cpcusb.html Ok, danke.
Rolf F. schrieb: > Ja, nur gibt es die in der Praxis nicht, also CAN-to_USB-Adapter die > selbstständig Zeitstempel erzeugen. Einen habe ich dir genannt. Die Systec-USBs macht es auch in board. Die Interfaces, die ich kenne, bieten aber nur eine Auflösung von 1ms. Zur Genauigkeit kann ich nichts sagen. Peter D. schrieb: > Zumindest haben viele CAN-Controller einen Timer, dessen Wert in jedem > MOB mit gespeichert wird, dagegen kannst Du nichts machen. Die wenigsten CAN Controller, die mir untergekommen sind, haben einen eigenen Timer. Teilweise ist dieser Timer nur einem einzigen MOB zugeordnet. Und die Auflösung des Timers ist von der Bitrate abhängig. Er hat sicherlich seine Berechtigung. Als Quelle für einen allgemeinen Zeitstempel aus meiner Sicht ungeeignet. Falls Du hier weitere Infos hast, würden diese mich interessiren. Rolf F. schrieb: > Das ist kein Problem, denn die Verzögerung liegt bei unter zwei > Mikrosekunden, für die Datenübertragung von der Karte zur CPU. > So mache ich Zeitstempel für passive Karten wie eine Paralleportkarte. OK. Die PCI Karten von EMS Wünsche sind passive Karten und enthalten (wenn ich mich recht erinnere) den SJA1000. Hier bildet das OS/der Treiber den Zeitstempel.
Gast
#4199468
Ich habe vom CanCase XL nochmal ins Handbuch geschaut http://vector.com/vi_cancase_xl_log_de.html das steht zur Timer Auflösung 1µs (das µ wird unter Linux im Okular nicht richtig dargestellt) Ich nutze die Version ohne Log und habe auch 15 Knoten mit 10 ms drauf ballern lassen und es funktionierte. In der Software ist auch der Zeitstempel auf 1µs aufgelöst. Die neuen kannst du sogar direkt extern synchronisieren.
Je nachdem, wie genau man es möchte, ist die Auflösung nicht so relevant wie die Genauigkeit (z.B. 1µs +/- 10µs). Allgemein gesprochen. Vector traue ich schon zu, direkt im CAN Controller den Zeitstempel zu bilden (siehe Kommentar von @Peter D.).
Günstiger als vector aber auch nicht schlecht sind die: https://esd.eu 73
Decius schrieb: > Ich danke es kommt darauf an, wieviel Funktionalität im CAN-Adapter > steckt und wieviel vom PC erledigt werden muss. Wenn ich mich recht > erinnere lag die minimale Intervallzeit der Windows-Timer bei 10ms, die > der hochauflösenden Timer bei 1ms. Unter Linux (mit RT_Preempt) habe ich eine Auflösung von 1 ns, laut clock_getres (). Und clock_nanosleep () arbeitet auch bei Port-Zugriffen auf 40 µs genau, d. h. Polling mit bis zu 25 kHz ist kein Problem.
CAN-Fan schrieb: > Ich habe vom CanCase XL nochmal ins Handbuch geschaut > > http://vector.com/vi_cancase_xl_log_de.html > > das steht zur Timer Auflösung 1µs (das µ wird unter Linux im Okular > nicht richtig dargestellt) 0k, 1 µs Auflösung, aber wie nahe ist das am tatsächlichen Wert? Werden beispielsweise zwei Datenpakete im Abstand von 40 µs auch mit dem Abstand gemeldet? Auflösung ist ja nicht gleich Genauigkeit und zudem kommt es noch darauf an worauf man das bezieht. Beispielsweise zeigt CANalyzer die Daten mit 0,1 ms Auflösung, aber nur mit 10 ms breiten Zeitscheiben, d. h. die Genauigkeit ist hundert mal größer als die Auflösung.
Rolf F. schrieb: > Werden beispielsweise zwei Datenpakete im Abstand von 40 µs auch mit dem > Abstand gemeldet? Da eine Botschaft mit einem Byte Nutzlänge schon 52 Bit hat wird man wohl kaum Botschaften im Abstand von 40µs finden. :-) Zwischen den Botschaften sind noch mindestens drei Bits "Interframe-Space". Aber eigentlich stellt sich die Frage so garnicht, man stopft den Bus nicht auf 100% voll.
Steffen R. schrieb: > Die wenigsten CAN Controller, die mir untergekommen sind, haben einen > eigenen Timer. Ich hab bisher nicht viele eingesetzt. Der alte SJA1000 hat sowas noch nicht. Die AT89C51CC03 und AT90CAN128 sind sehr ähnlich aufgebaut und haben einen Timer: "A programmable 16-bit timer is used for message stamping and time trigger communication. The capture of the timer value is done in the MOb which receives or sends the frame. All managed MOb are stamped, the stamping of a received (sent) frame occurs on RxOk (TXOK)." Damit kann man auch sehr bequem die Uhren aller CAN-Teilnehmer synchronisieren. Ein Slave schickt eine Nachricht und der Master antwortet, wann genau er sie empfangen hat. Der Slave muß dann nur noch seinen Sende-Timestamp davon abziehen.
Rudolph R. schrieb: > Rolf F. schrieb: >> Werden beispielsweise zwei Datenpakete im Abstand von 40 µs auch mit dem >> Abstand gemeldet? > > Da eine Botschaft mit einem Byte Nutzlänge schon 52 Bit hat wird man > wohl kaum Botschaften im Abstand von 40µs finden. :-) Das stimmt nicht ganz, denn ein Datenframe mit 0 Datenbytes hat 44 Bits, und wenn da was fehlt, kann man bei 1 Mbit/s durchaus 40 µs Differenz haben. In der Praxis sehe ich meist vollständige Frames und 50 bis 80 µs Abstand, siehe Bild mit einer Anfrage und fünf Antworten in einer halben Millisekunde. Also sollten Auflösung und Genauigkeit maximal 50 Mikrosekunden betragen.
Angehängte Dateien:
-
scope_0.png
(14 KB)
Rudolph R. schrieb: > Rolf F. schrieb: >> Werden beispielsweise zwei Datenpakete im Abstand von 40 µs auch mit dem >> Abstand gemeldet? > > Da eine Botschaft mit einem Byte Nutzlänge schon 52 Bit hat wird man > wohl kaum Botschaften im Abstand von 40µs finden. :-) > > Zwischen den Botschaften sind noch mindestens drei Bits > "Interframe-Space". Naja, die kürzeste Nachricht hat 0 Byte. Wenn Du meinst, dies wäre unsinnig (CANopen: Sync Nachricht), dann nimm eben RTR Messages. Wenn man dann noch Busfehler mitloggen will, kanns noch kürzer werden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.