Hallo,
wir bauen Messsensoren, von denen ich die Elektronik entwickle und die
bisher einen Analogausgang hatten.
Der Chef hat schon lange den Wunsch, Kunden auch eine
Digitalschnittstelle anbieten zu können. Das soll ich jetzt mit EtherCat
umsetzen.
Der verwendete Mikrocontroller SAM54D ist mit sehr zeitkritischen Sachen
schon zu 30% ausgelastet. Deshalb wäre wohl ein zusätzliches
EtherCat-Modul notwendig?
Mein Problem ist jetzt, dass ich von EtherCat, CAN etc. noch keine
Ahnung habe und auch nicht, was der Kunde anschließt und damit macht.
Wie / woher kann man da einen schnellen Einstieg bekommen?
Gibt es da gute Tutorials - um übehaupt mal einen Überblick zu bekommen?
(Möglichst mit Focus auf einen Sensor)
Bei Beckhoff habe ich mir schon einiges angeschaut, aber das ist alles
schon zu detailiert.
Wie / mit was kann ich am einfachsten ein Testsystem aufbauen?
Taugen die Kurse von Beckhoff was?
Wäre es ratsam eine externe Firma damit zu beauftragen? Welche?
Mit offensichtlich wenig Ahnung von der Materie bleiben eigentlich nur
fertige Module wie die von Anybus:
https://www.anybus.com/de/produkte/embedded-index/anybus-compactcom-modules
Da hat man alle möglichen industriellen Feldbusse zum Einstecken.
Allerdings haben die Module ihren Preis.
Falls Du das nicht willst:
Bei Ethercat brauchst Du auf der Slave-Seite sowieso einen Ethercat-Chip
(über SPI) bzw. eine CPU mit integriertem Ethercat-Chip. Aber damit ist
es noch lange nicht getan. Du musst dann einen fertigen SW-Stack bei Dir
adaptieren, EDS/ESI erzeugen, eine Hersteller-ID haben und wenn es für
externe Kunden sein soll auch noch einen Conformace-test.
Bei CAN nicht viel anders, die HW ist zwar einfacher, aber die Kunden
werden vermutlich CAN-OPEN haben wollen. Auch hier fertigen Stack
finden/kaufen, adaptieren, EDS erzeugen, evtl. Conformance-Test.
Das alles wird mit den Anybus-Modulen etwas einfacher. Wird deinem Chef
zu teuer sein, bei kleinen Stückzahlen(?) unter dem Strich aber dennoch
die wirtschaftlichste Lösung. Es gibt da Lehrgänge, wo einem die
Umsetzung gezeigt wird. Die ist für jedes Interface immer relativ
identisch.
Für Sensoren bietet sich doch Io-Link an.
Vendor, Device ID und ein IO-Link Stack wird zwar ebenso benötigt,
ist aber doch etwas weniger umfangreich als EtherCat.
Von Beckhoff gibt es auch ein Io Link Gateway.
Danke für die schnelle Rückmeldung.
>> Das alles wird mit den Anybus-Modulen etwas einfacher. Wird deinem Chef
zu teuer sein, bei kleinen Stückzahlen(?)
Ja, wir werden relativ kleine Stückzahlen haben, am Anfang wohl nur
einzelne. Wieviel kosten denn die so ungefähr?
Gibt es für den Anybus-CompactCom B40 Brick Tutorials / unterstützung?
Die Datenrate des Sensors ist ziemlich hoch, um die 4Mbit/s. Geht das
problemlos über EtherCat und angeschlossene Auswerteeinheiten?
Gibt es zum Beckhoff ET1100 ein Entwicklungskit?
Ist da der Master als PC-Programm enthalten?
Inwiefern ist der ET1100 einfacher zu implementieren als der Anybus?
Der Sensor soll einen Kanal für Messwertausgabe (out) und einen Kanal
für Konfigurationsdaten (in) haben.
Es sollen möglichst alle / mehrere in der Industrie gängigen Bussysteme
unterstützt werden können.
Was für ein µC ist denn der SAM54D, habe ich noch nie gehört.
Oder meinst Du SAM E54?
Brauchst Du wirklich eine Datenübertragung in Echtzeit (bei Ethercat
sind das um 1ms)? Ansonsten kann der SAM E54 doch schon USB und
Ethernet.
>> Oder meinst Du SAM E54?
Ja den.
>> Brauchst Du wirklich eine Datenübertragung in Echtzeit (bei Ethercat
sind das um 1ms)?
Ja auch, denn der Sensor soll auch für Regelungen einsetzbar sein.
Wieso 1ms? Ich dachte EtherCat ist so schnell und bietet Echtzeit?
TwinCat2 sollte der Master über eine Intel I210 funktionieren.. Ja gibt
es...
Nicht unwichtig, wo etherCat drauf steht ist auch etherCat drin. Beim
ASIC musst du glaube ich kein Mitglied sein. Der gibt sich als
Hauseigener Beckhoff ASIC zu erkennen.
Elektrolurch schrieb:> Wieso 1ms? Ich dachte EtherCat ist so schnell und bietet Echtzeit?
Die Industriebusse sind alle um 1ms rum. Ethercat geht soviel ich weiß
theoretisch bis 0,1ms runter, muss die SPS und vor allem die anderen
Teilnehmer am Bus aber auch unterstützen (typisch 1ms). Man könnte die
Daten jeweils zu 500 Byte packen, dann käme man bei 1ms Zykluszeit auch
auf 4MBit/s. Aber die SPS muss dann mit den Daten auch etwas anzufangen
wissen. Asynchrone Pakete kann man auch schicken, sind dann aber nicht
mehr "Echtzeit".
>> Ansonsten kann der SAM E54 doch schon USB und
Ethernet.
Deshalb habe ich diesen SAM zuerst gewählt.
Aber für das Serienprodukt werde ich den SAMx5x wählen, der nur das
benötigte drin hat.
EtherCat ist als Option (alternativ zu Analogausgang) vorgesehen.
Wie schon beschrieben, habe ich jetzt aber zeitkritische Routinen,
die </= 6µs verzögert werden dürfen.
Wenn ich nur die Datenausgabe machen muss, kann ich das über die DMA
nebenher laufen lassen. Ich habe ja noch keine Ahnung, welche
Reaktionszeiten Ethercat(-Modul) benötigt.
Außerdem ist mir ein geringst möglicher Implementationsaufwand wichtig.
Elektrolurch schrieb:>>> Oder meinst Du SAM E54?> Ja den.>>>> Brauchst Du wirklich eine Datenübertragung in Echtzeit (bei Ethercat> sind das um 1ms)?> Ja auch, denn der Sensor soll auch für Regelungen einsetzbar sein.> Wieso 1ms? Ich dachte EtherCat ist so schnell und bietet Echtzeit?
Was ist 1ms schnell?
Und was bedeutet Echtzeit? (Ich gehe mal von harter Echtzeit aus)
Vielen Dank für den Hinweis mit 1ms.
Das hatte ich nicht auf dem Schirm.
Der Sensor soll eigentlich bis 62,5kSPS Datenrate machen.
Da muss ich tatsächlich viele Messwerte zusammen in ein Paket packen.
Oder die Datenrate auf 1kSPS runter stutzen (wahlweise)...
Das Problem ist ja (auch) dass ich von der Kundenseite her keine Ahnung
habe, was die wollen brauchen anschließen.
Momentan haben wir ja noch keine konkreten Kunden, die man befragen
könnte..
Die Kunden werden den Sensor für Antriebsregelungen oder für
Kurvenaufzeichnungen einsetzen. Für die Kurvenaufzeichnung braucht es
dann die hohe Datenrate.
>> Und was bedeutet Echtzeit? (Ich gehe mal von harter Echtzeit aus)
Ich schätze mal, dass eine Antriebsregelung "harte" Echtzeit
voraussetzt?
Andererseits ist die Mechanik / Antieb ja auch nicht beliebig schnell.
Elektrolurch schrieb:>>> Und was bedeutet Echtzeit? (Ich gehe mal von harter Echtzeit> aus)> Ich schätze mal, dass eine Antriebsregelung "harte" Echtzeit> voraussetzt?> Andererseits ist die Mechanik / Antieb ja auch nicht beliebig schnell.
Mir ging es eher herauszufinden (und zu stänkern), ob er überhaupt weis,
was Echtzeit ist. Viele reden davon, aber haben keine Ahnung ^^
Elektrolurch schrieb:> Der Sensor soll eigentlich bis 62,5kSPS Datenrate machen.> Da muss ich tatsächlich viele Messwerte zusammen in ein Paket packen.> Oder die Datenrate auf 1kSPS runter stutzen (wahlweise)...Elektrolurch schrieb:> Außerdem ist mir ein geringst möglicher Implementationsaufwand wichtig.
Ich denke ein geringer Implementationsaufwand geht nur über
Buskonverter, bspw. auf Seriell. Die sind aber nicht schnell und
eingeschränkt. Mit ASIC bspw. über SPI wird man schnell und flexibel
(könnte also auch Daten packen), das geht dann aber eher nicht mehr
einfach. D.h. man muss den ASIC konfigurieren und sich auch mit dem
Protokoll/den Protokollen auskennen.
Elektrolurch schrieb:>>> Und was bedeutet Echtzeit? (Ich gehe mal von harter Echtzeit aus)> Ich schätze mal, dass eine Antriebsregelung "harte" Echtzeit> voraussetzt?
Ethercat schickt in jedem Zyklus ein Ethernetpaket zur synchronen
Übertragung. Das Paket durchläuft reihum alle Slaves und zurück zum
Master. Das Paket wird von jedem Slave jeweils quasi sofort
weitergeleitet. Deshalb ist auch spezielle Slave-Hardware notwendig.
Die zyklischen Slave-Daten haben jeweils eine feste Stelle im Paket und
jeder Slave schreibt dort seine Daten rein. Zu dem Zeitpunkt wo das
Paket ankommt, müssen also auch schon die Daten in der Slavehardware
bereitliegen. Und sollten natürlich sinnvollerweise auch Taktsynchron
aufgenommen/gesamplet werden. Ich denke bei einfachen Buskonvertern wird
das schon schwierig.
EtherCat ist (im Prinzip) nichts anderes als ein großes Schieberegister,
aber eben aus Ethernet-Hardware.
Dazu noch etwas Brimborium mit Logo, Lizenzgebühren, Vendor-Lock-In,
magischen Parametern und schlechter Doku oder Doku im
Kindergarten-Niveau. Dabei wird das System bei großen Installationen
schön unzuverlässig, Fehlersuche ein Grauen. Eben typischer, deutscher
Industriemist. Teuer und umständlich.
Elektrolurch schrieb:> Der Chef hat schon lange den Wunsch, Kunden auch eine> Digitalschnittstelle anbieten zu können. Das soll ich jetzt mit EtherCat> umsetzen.
und:
> Das Problem ist ja (auch) dass ich von der Kundenseite her keine Ahnung> habe, was die wollen brauchen anschließen.
Perfekt!
Ahnungsloser Chef, ahnungsloser Mitarbeiter, verkorkster Industriemist,
das Projekt wird der totaler Erfolg werden!
Zum Spielen von Infineon XMC4800 Relax EtherCAT Kit kaufen, ca. 50€.
Für den Einstieg die Applikationen ausprobieren. Für die spätere
Anwendung
den EtherCAT Slave Stack der ETG verwenden.
https://www.ethercat.org/de.htm
Timer schrieb:> Elektrolurch schrieb:>>>> Und was bedeutet Echtzeit? (Ich gehe mal von harter Echtzeit>> aus)>> Ich schätze mal, dass eine Antriebsregelung "harte" Echtzeit>> voraussetzt?>> Andererseits ist die Mechanik / Antieb ja auch nicht beliebig schnell.>> Mir ging es eher herauszufinden (und zu stänkern), ob er überhaupt weis,> was Echtzeit ist.
Man kann von seinen Antworten fast schon davon ausgehen das dem nicht so
ist.
Es geht darum vorgegebene Zeitfenster/Zeitspannen/Reaktionszeitn
einzuhalten und nicht "sofort", "superschnell" oder sonstwas. Wie groß
die Fenster sind hängt ganz vom konkreten Projekt ab und kann somit nur
der TO wissen (oder auch nicht:-)
- Zitate: https://de.wikipedia.org/wiki/Echtzeit
- "Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem
Programme zur Verarbeitung anfallender Daten ständig betriebsbereit
sind, derart, dass die Verarbeitungsergebnisse innerhalb einer
vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach
Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu
vorherbestimmten Zeitpunkten anfallen."
- "harte Echtzeit garantiert, dass die definierte Reaktionszeit niemals
überschritten wird."
Experte schrieb:> EtherCat ist (im Prinzip) nichts anderes als ein großes Schieberegister,> aber eben aus Ethernet-Hardware.>> Dazu noch etwas Brimborium mit Logo, Lizenzgebühren, Vendor-Lock-In,> magischen Parametern und schlechter Doku oder Doku im> Kindergarten-Niveau. Dabei wird das System bei großen Installationen> schön unzuverlässig, Fehlersuche ein Grauen. Eben typischer, deutscher> Industriemist. Teuer und umständlich.
Verwechselst Du das nicht mit Profinet? :-))
> Ahnungsloser Chef, ahnungsloser Mitarbeiter, verkorkster Industriemist,> das Projekt wird der totaler Erfolg werden!
Ein Wissender spricht aus leidvoller Erfahrung? Ich kann`s nur
bestätigen das solche "Industrie"Lösungen alles andere als einfach zu
implementieren sind, vor allem wenn man eine Blackbox vor sich hat
die.... ausreichend gruselig dokumentiert ist....
Viel Grlück und vor allem - wenn ihr das macht sofort dem
entsprechenden Verein beitreten (Chef will das, also soll er auch
zahlen, sein und nicht Dein Problem) und wenn ihr dem Verein beigetreten
seid jede noch so depperte Frage dort klären lassen. Sollen die was tun
für die Beitrittsgebühren. BTDT.
Elektrolurch schrieb:> Der Chef hat schon lange den Wunsch, Kunden auch eine> Digitalschnittstelle anbieten zu können. Das soll ich jetzt mit EtherCat> umsetzen.
Ich wage hier mal zu bezweifeln, dass diesem Wunsch ein "echter" Bedarf
gegenüber steht! Wenn ihr eine (deine) funktionierende analoge Sensorik
habt und es da auch Kunden gibt, dann bleibt einfach bei der analogen
Schnittstelle. Es ist ja nicht so, dass in der Industrie jetzt alles und
Jedes mit allen möglichen Schnittstellen ausgerüstet sein muß. Schon
sowas für einen "ausgesuchten" Kunden aus Nettigkeit zu veranstalten,
kann erhebliche Probleme aufwerfen - wie man gerade in einem
Nachbarfaden nachlesen kann. Und wenn eine bestimmte Schnittstelle für
den Kunden das OK-Kriterium ist, dann ist es das eben...
Gruß Rainer
>> Ich wage hier mal zu bezweifeln, dass diesem Wunsch ein "echter" Bedarf
gegenüber steht!
Naja, immerhin bietet ein größerer Wettbewerber (und Kunde!) das an.
Außerdem finde ich es schade, wenn ein digitales Datensignal wieder in
analog umgewandelt wird und dann von digitalen Steuerungen /
Auswertegeräten wieder digitalisiert wird...
Was mich noch interessieren würde:
- wie erlangt das EtherCAT-Empfangsgerät / Master? die Info, welches
Datenformat etc. es benutzen soll?
Anders gefragt, wie wird der Empfänger darauf parametrisiert?
Gibt es da standardisierte / vordefinierte Protokolle?
- Wenn der Sensor parametrierbar ist, wie wird das bewerkstelligt?
- Wenn man das Beckhoff Experimentierboard für einen Slave verwendet,
muss es doch einen Master geben. Wo kommt der her? Ist der auch mit auf
dem Board?
Elektrolurch schrieb:> - wie erlangt das EtherCAT-Empfangsgerät / Master? die Info, welches> Datenformat etc. es benutzen soll?
EtherCat-Description, da speziell die PDOs für den zyklischen
Datenaustausch.
> - Wenn der Sensor parametrierbar ist, wie wird das bewerkstelligt?
Über Startup-Listen; es wird eben über die Indexe entsprechende Werte in
die Objekte geschrieben.
Welche Objekte es so gibt, steht im Objekt-Verzeichnis.
> - Wenn man das Beckhoff Experimentierboard für einen Slave verwendet,> muss es doch einen Master geben. Wo kommt der her? Ist der auch mit auf> dem Board?
Master ist z.B. eine SPS, oder auch ein TwinCAT auf Deinem Notebook,
sofern kompatible Hardware vorhanden.
Wie gesagt, noch nie mit Industrie-Bussen rumgemacht? Dann viel Spaß!
@ Experte:
Vielen Dank schonmal für deine Hinweise.
Wie hast du dich da eingearbeitet?
Gibt es gute Bücher zum Einlernen?
Was taugen die Beckhoff-Kurse?
Elektrolurch schrieb:> Naja, immerhin bietet ein größerer Wettbewerber (und Kunde!) das an.
Wie macht der das mit der (hohen) Datenrate?
> Außerdem finde ich es schade, wenn ein digitales Datensignal wieder in> analog umgewandelt wird und dann von digitalen Steuerungen /> Auswertegeräten wieder digitalisiert wird...
Ist sicher ein Verkaufsargument, selbst wenns nicht direkt gebraucht
wird ("Zukunftsfähigkeit"). Aber wenns halt zu teuer wird...
> Gibt es da standardisierte / vordefinierte Protokolle?> - Wenn der Sensor parametrierbar ist, wie wird das bewerkstelligt?
Ja, es gibt die synchronen Daten, die mit jedem Takt versendet werden
und die asynchronen, die nur bei Bedarf geschickt werden. Die
asynchronen verwendet man zur Parametrisierung. Das sind quasi Register
im Slave, die der Master lesen und schreiben kann, wann er möchte, bspw.
in der Initialisierungsphase. Jedes Datenobjekt hat einen
definierten/definierbaren Datentyp.
Aber wenn du an das Thema ran möchtest, musst du das alles selber
lernen. Das jetzt nur mal als Überblick, ob das Protokoll für euch
überhaupt in Frage kommt.
> - Wenn man das Beckhoff Experimentierboard für einen Slave verwendet,> muss es doch einen Master geben. Wo kommt der her? Ist der auch mit auf> dem Board?
Normalerweise ist die SPS der Master.
Prinzipiell braucht es keine spezielle Ethercat-Hardware auf
Masterseite, ein PC oder Mikrocontroller mit Ethernet genügt. Natürlich
braucht es einen Ethercat-Stack, den baut man sich nicht selber. Bspw.
SOEM ist eine solche Bibliothek für einen Ethercat-Master, sogar
Open-Source. Zum Testen des eigenen Slaves und zum Verständnis des
Protokolls ist es m.E. ganz hilfreich.
Allerdings braucht es für eine Echtzeitkommunikation auch ein
echtzeitfähiges System, was auf dem PC schon schwierig wird. Die
prinzipielle Kommunikation kann man damit trotzdem testen.
Insgesamt würde ich sagen, dass man im Grunde eine Person langfristig
fest für das Thema Ethercat abstellen muss, wenn man es selber und
ordentlich umsetzen möchte.
Maxe schrieb:> Normalerweise ist die SPS der Master.
Was ist dann aber mit dem TwinCAT? Das läuft doch unter Visual Studio -
und desshalb auf dem PC. Kann man dann das damit entwickelte Programm
auf die SPS draufspielen?
Also, ich habe jetzt mal geschaut und vom Vorgänger folgendes gefunden:
- CX8190 mit EK1110
-EL9800
Das sind doch beides Slaves?
CX8190 als Fertigmodul und EL9800 als Entwicklungskit?
Wie sieht es mit der TwinCAT-Software aus, wird die runtergeladen und
man kauft nur die Lizenz, oder kommt das auf CD/DVD mit?
Gibt es kompetente Firmen, die man mit der Implementierung der
EtherCAT-Seite beauftragen kann?
Wenn Ihr noch gar keine Erfahrung im Bereich der Industriellen
Kommunikation habt, dann geht mal davon aus das Ihr, wenn ihr eine
vorgefertigte Lösung integriert, mindestens ein Mannjahr pro System
(Ethercat, Ethernet/IP, Profinet) investieren müsst. Auch in diesem Fall
müsst Ihr mit euren Geräten zu Zertifizierungstests für das jeweilige
System. Ein Profinetgerät darf man z.B. nur damit bewerben, wenn man ein
solches Testzertifikat hat. Kosten alleine für den Test liegen im
mittleren vierstelligen Bereich.
Wenn Ihr das ganze selber entwickeln wollt: also bei uns arbeiten seit
>10 Jahren an jedem dieser Systeme jweils >3 Mitarbeiter. (Testabteilung
und Support nicht mitgezählt) Und es gibt jedes Jahr was Neues. Wir
haben genug Arbeit. Wenn Ihr diesen Weg geht, müsst Ihr euch darauf
Einstellen einen großen Gerätepark and PLCs unterschiedlichster
Hersteller, Versionstände etc vorzuhalten. Kompatibilität existiert im
Wesentlichen nur auf dem Papier...
Ich habe auch das Gefühl, das euer Anwendungsfall nicht ganz passt.
Typischerweise wird an eine PLC nur der aktuelle Messwert übertragen.
PLCs sind nicht dafür gemacht Kurven aufzuzeichnen und abzuspeichern.
Intern funktionieren PLC im Prinzip wie eine CPU die auf einem
virtuellen Speicher arbeitet, bei dem jedem an der PLC angeschlossenem
Gerät ein kleiner Teil dieses Speichers zugeordnet wird. Das
Kommunikationsprotokoll sorgt dafür, dass dieser Speicher periodisch
(typ 1ms) aktualisiert wird.
Typische PLCs haben in der Größenordnung 4-8k Prozessdaten. Wenn Dein
Gerät davon 500 Byte belegen will werden die Automatisierer nicht sehr
glücklich sein. Bedenke auch, das 500Byte ca. 50µs für die Übertragung
benötigt werden, d.h. Dein Gerät belegt bei z.B. Profinet alleine schon
10% der Verfügbaren Bandbreite bei 1ms Bustakt. (Bei Profinet dürfen nur
50% für Prozessdaten benutzt werden). Dazu ist bei Profinet nur bis ca
240 Byte Größe die Datenkonsistenz garantiert. (Hardwarebeschränkung
alter Implementierungen....)
Ich vermute mal bei den Kurven gehts um QA bzw. Protokollierung der
Produktionschritte. Das macht man meist indem die Geräte (Parallel zur
Verbindung mit der PLC) diese Daten an irgendeinen "Edge-Server" oder an
ein der PLC übergeordnetem Steuersystem (meist ein PC) schicken bzw. von
diesem holen lassen.
