TIA Erfahrungen CAN/CANopen

K

KarlMeier

Level-2
Beiträge
247
Reaktionspunkte
36
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
ich bräuchte mal wieder euer Fachwissen.

Der Grund für meine Frage bezieht sich auf folgendes Thema:

K

TIA Thema 'OPCUA oder Profinet?'

Hallo zusammen!
Es geht um ein Projekt bei dem ein Datenaustausch zwischen einer Siemens S7 1513 und einer B&R X20 CP1585 realisiert werden soll. Es geht um den Datenaustausch in beide Richtungen. Die Größe der Daten ist erstmal nicht relevant. Es sind 2-3 Bytes Statusmeldungen, sowie einige Integer und Real/Float-Werte. Also nichts was den Rahmen sprengen würde.
Der Maschinenhersteller mit der B&R-Steuerung besteht auf OPCUA, ist dabei auch ziemlich unflexibel, der Anlagenbetreiber mit der Siemens S7 möchte unbedingt Profinet.
Ich bin auch der Meinung, dass die Profinet-Lösung sinnvoller...

Ich konnte mich mit dem Fremdmaschinenhersteller nicht einigen, da ich OPCUA abgelehnt habe und dieser wiederum hat Profinet abgelehnt. Jetzt wurde ein Kompromiss in den Raum gestellt, welcher vom Fremdmaschinenhersteller umsetzbar wäre. Und zwar würde der Datenaustausch via Can/CanOpen realisiert werden. Ich hab keinerlei Erfahrung mit Can oder CanOpen, jedenfalls nicht in Verbindung mit Siemens S7.

Ich hab nun 2 Fragen. Die erste ist, ob es Erfahrungen gibt wie gut CAN für den Echtzeit-Datenaustausch funktioniert? Meine Erfahrungen mit CAN beziehen sich auf Fremdmaschinen, welche ihre Frequenzumrichter und IO-Module via CAN in die Steuerung einbinden. Die alten, blauen B&R-Steuerungen haben glaub ich nur mit CAN gearbeitet. Wie seht ihr den CAN-Bus allgemein? Ist es ein veraltetes Feldbus-System, welches ähnlich wie Profibus langsam verabschiedet werden sollte?

Die zweite Frage bezieht sich auf die Einbindung in die S7-1500. Ich habe 2 Siemens-eigene Lösungen gefunden, zum Einen die Anbindung mittels Kommunikationsmodul für die ET200SP


zum Anderen die Anbindung mittels PN/CAN-Konverter:


Als dritte Variante hab ich noch ein PN/CAN-Gateway von Helmholz gefunden:
www.helmholz.de

PROFINET / CAN-Gateway

Mit dem PN/CAN-Gateway ist eine einfache und unkomplizierte Anbindung von CAN-Geräten an ein PROFINET-Netzwerk möglich.
www.helmholz.de www.helmholz.de

Kann mir hierzu jemand etwas sagen? Gibt es Meinungen dazu? Wie funktioniert die Einbindung? Ist es recht kompliziert/komplex? Funktioniert es stabil oder muss man erfahrungsgemäß ewig dran rumbasteln bis es endlich funktioniert?
 
Also canOpen für die Kommunikation für 2 sps in der heutigen Zeit ist echt das dümmste was ihr euch einigen konntet. Sorry für diese Ausdruck. Wenn die Signale nicht zeitkritisch sind währe meiner Meinung nach OPC UA echt die bessere Alternative. Can Open tut ihr euch in diesem Fall beide keinen Gefallen. Ich kenne can Open und OPC UA. Allein schon die Hardware für die Kommunikation. OPC UA geht über Ethernet und das können beide. Und OPC ist mehr ein zusammen klicken der Kommunikation als Programming. Und wenn es Probleme gibt mit der Kommunikation gibt es für OPC einige Tools teils für umsonst. Can Open ist da ein kostspieligere und komplizierte Angelegenheit
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe ein bisschen Erfahrung mit CAN, aber nicht mit Siemens. Es war mit B&R 2003 System.
CAN ist eine realen 'Feld-bus' und ähnlich zu Profibus. CAN ist deterministisch und es sollte nicht möglich sein, dass es zu Unterbrechungen oder Abweichungen kommt, wie du mit OPC UA erlebt hast.

Mit die beide Lösungen habe ich keine Erfahrung.
Ich wurde nach das ET200SP Modul tendieren. Damit hast du Diagnostik direkt mit TIA. Ich vermute das in das Anwenderprogramm kann man eine Status bekommen, damit man mit das Anwenderprogramm auf CAN Bus Probleme reagieren kann.

Ich wurde aber mit die Endkunde die Hersteller fragen warum er diesen Modul in sein System nicht einbauen kann:
 
Can Open ist im Siemens Universum ein totaler Exot da gibt es nicht viel Hardware für die Kommunikation. Can Open ist im Bereich von Fahrzeugen eine optimale Wahl, aber im Bereich der Automatisierung??
 
Danke für die Antworten.
Wir haben uns bis jetzt noch nicht darauf geeinigt, sondern es war von Seiten des Maschinenherstellers ein Kompromissvorschlag, ich sagte aber bereits, dass ich mich da erstmal schlau machen muss, weil ich mich damit noch nie befasst hab. Insbesondere, wie erwähnt, nicht in Verbindung mit Siemens.
Also denkt ihr, dass CAN auch nicht die Lösung ist?

Mir wäre natürlich die direkte PN-Schnittstelle an der B&R-Steuerung am liebsten, aber da stellt sich der Hersteller quer.
 
Heute gibt es doch für alles Gateways. Du nimmst auf deiner Seite Profinet und der Kollege sucht sich halt sein Lieblingsprotokoll aus.

In einer meiner letzten Retrofit Anlagen gab es eine Kopplung über digitale IOs. Jeweils eine ET200B 16DI / 16DO nebeneinander. So wäre wahrscheinlich auch noch eine Möglichkeit :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
oliver.tonn schrieb:
Bringt Dich jetzt leider nicht weiter, aber warum lehnt der Maschinenhersteller PROFINET ab und Du OPC UA, das sind doch beides gängige Übertragungsmöglichkeiten
Zum Vergrößern anklicken....
Ich hab das in dem anderen Beitrag schonmal erklärt. OPCUA lehne ich aus folgenden Gründen ab:
- Beide Steuerungen befinden sich in unterschiedlichen IP-Netzen. Technisch also nur realisierbar mit 2 Firewalls und weiteren Netzwerkkomponenten um die Netze getrennt zu halten.
- Auch durch oben genannten Umstand bedingt, entsteht eine sehr instabile Schnittstelle, wo ich auf der B&R-Seite keinerlei Zugriffsmöglichkeiten hab.
- Kleine aber vorhandene Performance-Verschlechterung der Serverseite
- Es geht um einen mittelmäßig zeitkritischen Datenaustausch und da halte ich OPCUA nunmal nicht für geeignet. OPCUA ist meiner Meinung nach dafür gedacht den plattformunabhängigen Datenaustausch zu übergeordneten Systemen zu ermöglichen. Um 2 CPUs miteinander sprechen zu lassen gibt es aktuelle und fortschrittliche, netzwerkbasierende Feldbuslösungen, welche in „Echtzeit“ miteinander sprechen und Daten austauschen.

Der Hersteller lehnt das PN-Modul ab, weil es noch nie im Maschinenportfolio verwendet wurde. In der weiteren Argumentation wird angeführt dass man dann die Servicetechniker speziell auf dieses neue Modul schulen müsste, es müssen Ersatzteile vorrätig gehalten werden, es muss die Software und Hardwarekonfiguration angepasst werden, welche wohl bei allen Anlagen standardisiert gleich ist usw. Man ist also ziemlich unflexibel auf Kundenwünsche einzugehen.
 
oliver.tonn schrieb:
Bringt Dich jetzt leider nicht weiter, aber warum lehnt der Maschinenhersteller PROFINET ab und Du OPC UA, das sind doch beides gängige Übertragungsmöglichkeiten
Zum Vergrößern anklicken....
Wobei ich, bezüglich OPC UA, jetzt auch nicht auf die Idee kommen würde, das für irgendwas zu nehmen, was auch nur im entferntesten "Echtzeitanforderungen" stellt, und das relativ egal wie auch immer man Echtzeit im jeweiligen Kontext nun definiert.

Wobei ich mich gerade tatsächlich ein wenig frage, warum man nicht einfach 08/15 Ethernet Standardprotokolle verwendet, also irgendwas zwischen Modbus TCP, oder wirklich einer ordinären TCP-Verbindung?

KarlMeier schrieb:
Der Hersteller lehnt das PN-Modul ab, weil es noch nie verwendet wurde. In der weiteren Argumentation wird angeführt dass man dann die Servicetechniker speziell auf dieses neue Modul schulen müsste, es müssen Ersatzteile vorrätig gehalten werden, es muss die Software und Hardwarekonfiguration angepasst werden, welche wohl bei allen Anlagen standardisiert gleich ist usw. Man ist also ziemlich unflexibel auf Kundenwünsche einzugehen.
Zum Vergrößern anklicken....
Und wie genau passt hier dann Can/Canopen ins Schema?
 
Blockmove schrieb:
Heute gibt es doch für alles Gateways. Du nimmst auf deiner Seite Profinet und der Kollege sucht sich halt sein Lieblingsprotokoll aus.

In einer meiner letzten Retrofit Anlagen gab es eine Kopplung über digitale IOs. Jeweils eine ET200B 16DI / 16DO nebeneinander. So wäre wahrscheinlich auch noch eine Möglichkeit :)
Zum Vergrößern anklicken....

Sowas mache ich wenn ich Altanlagen an eine neue Anlage anbinden muss/möchte, nicht aber bei einer Neuanlage. 😜
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MSB schrieb:
Wobei ich mich gerade tatsächlich ein wenig frage, warum man nicht einfach 08/15 Ethernet Standardprotokolle verwendet, also irgendwas zwischen Modbus TCP, oder wirklich einer ordinären TCP-Verbindung?
Zum Vergrößern anklicken....
Zum Einen hätte man das gleiche Netzwerkproblem mit den unterschiedlichen IP-Bereichen, wobei hier wahrscheinlich die Verbindungs- und Übertragungsstabilität besser wäre. Zum Anderen wäre das aber auch eine „Abweichung vom Standard“ von Seiten des Maschinenherstellers, welcher offenbar nicht möglich ist. Sei es nun weil man es wirklich nicht kann (unwahrscheinlich) oder weil man einfach nicht will.

MSB schrieb:
Und wie genau passt hier dann Can/Canopen ins Schema?
Zum Vergrößern anklicken....
Dies hat man offenbar im Herstellerstandard abgedeckt…
 
Ich habs im original Thread schonmal gelesen, aber möchte trotzdem nochmal nachfragen. Wenn du nur wenige Bytes austauschen möchtest. Was spricht da gegen einen Koppler? Das ist doch viel simpler zu warten als jede andere dahingefummelte Verbindung.
 
Salli1991 schrieb:
Ich habs im original Thread schonmal gelesen, aber möchte trotzdem nochmal nachfragen. Wenn du nur wenige Bytes austauschen möchtest. Was spricht da gegen einen Koppler? Das ist doch viel simpler zu warten als jede andere dahingefummelte Verbindung.
Zum Vergrößern anklicken....
Was möchtest du denn koppeln, wenn beide CPUs unterschiedliche Sprachen sprechen?

Ein Koppler bringt mir ja nur etwas, wenn beide CPUs die gleiche Feldbussprache sprechen, sich aber in verschiedenen Subnetzbereichen befinden.

Darum sollte es reichen wenn man der B&R-CPU ermöglicht Profinet zu sprechen. Das kann dann direkt von der Siemens CPU verstanden werden, ohne dass ein Koppler nötig ist.

Oder meinst du etwas anderes?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
KarlMeier schrieb:
Was möchtest du denn koppeln, wenn beide CPUs unterschiedliche Sprachen sprechen?

Ein Koppler bringt mir ja nur etwas, wenn beide CPUs die gleiche Feldbussprache sprechen, sich aber in verschiedenen Subnetzbereichen befinden.
Zum Vergrößern anklicken....

Es gibt auch Koppler zwischen verschiedenen Feldbuse


Anybus X-gateway – CANopen Slave - PROFINET-IO Device

Protokollkonverter zur Verbindung von CANopen- und PROFINET-IO-Steuerungen
www.hms-networks.com www.hms-networks.com
 
van schrieb:
Es gibt auch Koppler zwischen verschiedenen Feldbuse


Anybus X-gateway – CANopen Slave - PROFINET-IO Device

Protokollkonverter zur Verbindung von CANopen- und PROFINET-IO-Steuerungen
www.hms-networks.com www.hms-networks.com
Zum Vergrößern anklicken....
Ja das ist ein Gateway (Konverter, Übersetzer), im Grunde genommen das Gleiche was ich im Beitrag #1 genannt hab, nur eben nicht von Siemens oder Helmholz, sondern von Anybus.

Dies würde aber auch wieder eine CANopen-Implementierung erfordern und CAN ist hier wohl auch nicht das Gelbe vom Ei. Ich kann es nicht einschätzen…
 
Warum?
Mit zB einem PN/Can Koppler kann doch jede Sps ihren Lieblings Bus verwenden. Und muss sich um die andere Seite keine Gedanken machen.

Was auch immer der Lieblings Bus der B&R Sps ist. Die Koppler gibts ja für alle Feldbus Kombinationen.

Und dann werden einfach zB 32 bytes in beide Richtungen hin und her geschoben.
Zumindest denke ich mir das so.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
van schrieb:
Warum?
Mit zB einem PN/Can Koppler kann doch jede Sps ihren Lieblings Bus verwenden. Und muss sich um die andere Seite keine Gedanken machen.

Was auch immer der Lieblings Bus der B&R Sps ist. Die Koppler gibts ja für alle Feldbus Kombinationen.

Und dann werden einfach zB 32 bytes in beide Richtungen hin und her geschoben.
Zumindest denke ich mir das so.
Zum Vergrößern anklicken....
Wenn es so einfach gehen würde, dann wäre das ja ne feine Sache, aber ganz so leicht funktioniert es vermutlich nicht.

Man muss doch diese Konverter/Gateways selbst auch noch programmieren und parametrieren, Datenstruktur hinterlegen usw. damit sie die jeweiligen Busprotokolle entsprechend umwandeln können.

Bei Anybus gibt es hierfür sicherlich eine Weboberfläche um das alles einzustellen (keine Ahnung wie umfangreich und aufwendig das ist), bei Siemens macht man das alles über die Gerätekonfiguration. Beispielhaft habe ich das in diesem Video mal gesehen. Die Prozedur ist sicherlich gleich mit dem ET200-Modul.

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
An deiner Stelle würde ich deinem Zulieferer das Helmholz Can/PN-Gateway als Schnittstelle vorsetzen und als gewünschte Lösung präsentieren.
Du kümmerst Dich um den PN-Teil, der Partner hat sein gewünschtes CAN.

Auf der Helmholz-Seite wird mit folgendem Punkt geworben, kann also nicht so wild sein.
  • Keine Hantierungsbausteine oder Parametriersoftware notwendig
Ansonsten kann jeder von Euch beiden bei Helmholz anrufen. Die wissen was eine IBN ist und helfen schnell und pragmatisch bei Problemen.
 
Holzmichl schrieb:
An deiner Stelle würde ich deinem Zulieferer das Helmholz Can/PN-Gateway als Schnittstelle vorsetzen und als gewünschte Lösung präsentieren.
Du kümmerst Dich um den PN-Teil, der Partner hat sein gewünschtes CAN.

Auf der Helmholz-Seite wird mit folgendem Punkt geworben, kann also nicht so wild sein.
  • Keine Hantierungsbausteine oder Parametriersoftware notwendig
Ansonsten kann jeder von Euch beiden bei Helmholz anrufen. Die wissen was eine IBN ist und helfen schnell und pragmatisch bei Problemen.
Zum Vergrößern anklicken....

Hab mir das Helmholz-Gateway und das Handbuch nochmal genauer angesehen. Ich glaube dass du Recht hast. Es sieht für mich wie die „beste“ Lösung der Problematik aus.
Zusätzlich würde es auch den Verantwortungsbereich klar trennen.

Hat jemand Erfahrungen damit wie gut/stabil das Helmholz-Gateway funktioniert ?
 

Similar threads

D
TIA Erfahrung mit CANopen an Tia / Siemens? Digitale Drucktransmitter
Antworten
5
Aufrufe
7K
maxder2te
M
Zurück
Oben