Wenn ich bei Google nach "Hohlwelttheorie" suche, bekomme ich auch jede Menge Ergebnisse, die deswegen aber auch nicht richtig sind.
Und wenn du schon Wikipedia zitierst, dann versuche vielleicht auch mal zu verstehen, was dort steht:
> Der CAN-Bus (Controller Area Network) ist ein asynchrones, > serielles Bussystem und gehört zu den Feldbussen.
Das ist vollkommen richtig, hier geht es um "CAN", die Hardware, die Schnittstelle.
"CANopen" wiederum ist etwas komplett anderes, hier geht es um eine Kommunikationsprotokoll, welches im Prinzip von der darunter liegenden Hardware unabhängig ist.
Und deswegen ist es eben schlichtweg nur falsch, wenn auf der PVBrowser-Webseite "CAN" unter "Protokolle" aufgeführt wird.
"CANopen" hat auf Wikipedia sogar eine eigene Seite, wenn du dir die Mühe gemacht hättest, die auch mal zu suchen, wäre dir der Unterschied längst aufgegangen.
Ich hoffe übrigens, das du mit dem Projekt nichts zu tun hast. Bei derart eklatanten Wissenslücken wäre das keine gute Werbung für das Tool.
> INTRODUCTION > The Controller Area Network (CAN) is a serial communications protocol > which efficiently supports distributed realtime control with a > very high level of security. Siehe: http://www.can-cia.de/fileadmin/cia/specifications/CAN20A.pdf
pvbrowser kann prinzipiell an jedes Feldbussystem / an jede SPS gekoppelt werden. Es gibt aber Schnittstellen, die "out of the box" einsatzfähig sind.
Beispielsweise können Hilscher CIF Karten eingesetzt werden (u.a. für CAN). http://de.hilscher.com/products_group_pccards.html
Modbus ist besonders hervorzuheben, weil dieses Protokoll offen dokumentiert ist. Sehr viele Geräte unterstützen Modbus. Es gibt Gateways die eine Brücke von Modbus auf andere Protokolle schlagen.
Viele Protokolle im diesem Bereich sind nicht offen dokumentiert oder es fallen Lizenzkosten an. Beispiele dafür sind die Protokolle um Siemens SPS anzubinden oder das in Amerika stark verbreitete Ethernet/IP von Rockwell. Es gibt aber "reverse engineerte" Bibliotheken, die diese Protokolle unterstützen.
Der quasi Standard OPC ist in seiner traditionellen Form an Windows gebunden, weil er auf COM/DCOM von Microsoft aufbaut. Aber OPC wird mit OPC UA nun auch portierbar. Es fallen dort aber Lizenzkosten an. Bei uns wird "out of the box" OPC XML-DA unterstützt.
Für pvbrowser stellt es kein prinzipielles Problem dar "jedes" Protokoll zu unterstützen. - Entweder wird das Protokoll nativ unterstützt. - Oder es kann über ein Gateway eingebunden werden. - Oder es gibt eine Bibliothek von einem Fremdhersteller (evtl. Closed Source).
Das Prinzip der Datenerfassung mit pvbrowser wird in diesem Bild dargestellt. http://pvbrowser.de/pvbrowser/pic/prinzip.png Die Anbindung wird über jeweils einen daemon für ein bestimmtes Protokoll realisiert. Der daemon tauscht dann die Daten über ein Shared Memory und eine Mailbox mit dem Visualisierungs-Server aus.
Auf ISO/OSI Schicht 2 gibt es auch ein Prtokoll.
CANopen ist dann ein Schicht 7 Protokoll.
Siehe:
google: can protokoll
Z.B.
CAN protocol specification
http://www.can-cia.de/index.php?id=164
Wenn ich bei Google nach "Hohlwelttheorie" suche, bekomme ich auch jede Menge Ergebnisse, die deswegen aber auch nicht richtig sind.
Und wenn du schon Wikipedia zitierst, dann versuche vielleicht auch mal zu verstehen, was dort steht:
> Der CAN-Bus (Controller Area Network) ist ein asynchrones,
> serielles Bussystem und gehört zu den Feldbussen.
Das ist vollkommen richtig, hier geht es um "CAN", die Hardware, die Schnittstelle.
"CANopen" wiederum ist etwas komplett anderes, hier geht es um eine Kommunikationsprotokoll, welches im Prinzip von der darunter liegenden Hardware unabhängig ist.
Und deswegen ist es eben schlichtweg nur falsch, wenn auf der PVBrowser-Webseite "CAN" unter "Protokolle" aufgeführt wird.
"CANopen" hat auf Wikipedia sogar eine eigene Seite, wenn du dir die Mühe gemacht hättest, die auch mal zu suchen, wäre dir der Unterschied längst aufgegangen.
Ich hoffe übrigens, das du mit dem Projekt nichts zu tun hast. Bei derart eklatanten Wissenslücken wäre das keine gute Werbung für das Tool.
Lass uns mal hier keine Haarspalterei betreiben.
> INTRODUCTION
> The Controller Area Network (CAN) is a serial communications protocol
> which efficiently supports distributed realtime control with a
> very high level of security.
Siehe:
http://www.can-cia.de/fileadmin/cia/specifications/CAN20A.pdf
PS: Ich habe mit pvbrowser zu tun.
Hintergrundinformationen:
pvbrowser kann prinzipiell an jedes Feldbussystem / an jede SPS gekoppelt werden.
Es gibt aber Schnittstellen, die "out of the box" einsatzfähig sind.
Beispielsweise können Hilscher CIF Karten eingesetzt werden (u.a. für CAN).
http://de.hilscher.com/products_group_pccards.html
Modbus ist besonders hervorzuheben, weil dieses Protokoll offen dokumentiert ist.
Sehr viele Geräte unterstützen Modbus.
Es gibt Gateways die eine Brücke von Modbus auf andere Protokolle schlagen.
Viele Protokolle im diesem Bereich sind nicht offen dokumentiert oder es fallen Lizenzkosten an.
Beispiele dafür sind die Protokolle um Siemens SPS anzubinden oder das in Amerika stark verbreitete Ethernet/IP von Rockwell.
Es gibt aber "reverse engineerte" Bibliotheken, die diese Protokolle unterstützen.
Der quasi Standard OPC ist in seiner traditionellen Form an Windows gebunden, weil er auf COM/DCOM von Microsoft aufbaut.
Aber OPC wird mit OPC UA nun auch portierbar.
Es fallen dort aber Lizenzkosten an.
Bei uns wird "out of the box" OPC XML-DA unterstützt.
Für pvbrowser stellt es kein prinzipielles Problem dar "jedes" Protokoll zu unterstützen.
- Entweder wird das Protokoll nativ unterstützt.
- Oder es kann über ein Gateway eingebunden werden.
- Oder es gibt eine Bibliothek von einem Fremdhersteller (evtl. Closed Source).
Das Prinzip der Datenerfassung mit pvbrowser wird in diesem Bild dargestellt.
http://pvbrowser.de/pvbrowser/pic/prinzip.png
Die Anbindung wird über jeweils einen daemon für ein bestimmtes Protokoll realisiert.
Der daemon tauscht dann die Daten über ein Shared Memory und eine Mailbox mit dem Visualisierungs-Server aus.