Pixtend-L(tm) open source clone: Transformer PLC

[Revo B. (michael_s23)]

Hallo zusammen,

ich bin gerade dabei, die Transformer-PLC zu konzipieren. Dieses Gerät 
für Industrie- und Heimautomatisierung soll den Umstieg/Transformation 
von traditionellen, zentralistischen PLCs (nach IEC-61131) auf die neue, 
verteilte Automatisierung (nach IEC-61499) vereinfachen. Daneben soll es 
auch die Kontron Pixtend v2 -L- emulieren. Ich möchte noch anmerken, 
dass ich nichts mit der Firma Kontron zu tun habe. Die Pixtend v2 -L- 
wurde eher zufällig als Vertreter traditioneller IEC-61131 Entwicklung 
ausgewählt, auch weil sie gut dokumentiert ist, in D. weit verbreitet 
und in diesem Forum vorgestellt wurde.


Die Transformer-PLC wird open source sein, nach dem "Teensy" Konzept: 
Alles ist open source, ausser dem (Bootloader beim Teensy) BIOS (bei der 
Transformer-PLC). Das ermöglicht Gerätereparatur für Besitzer, und 
verhindert Trittbrettfahrer, die einfach ohne Eigenleistung ein Geschäft 
machen wollen.

Hier die Eckdaten:

-identisch zur Pixtend v2 -L-:

16 x digitale Eingänge

12 x digitale Ausgäge

4 x analoge Spannungs-Eingänge

2 x analoge Strom-Eingänge

2 x analoge Spannungsausgänge

2 x analoge Stromausgänge

4 x Relay

4 x GPIO

6 x PWM

alle Ein-/Ausgänge sind entprechend geschützt nach den gültigen PLC 
Normen.

- RS232, RS485

- CAN oder FD-CAN kann als Erweitungsmodul nachgerüstet werden.

- 24V externe Versorgungsspannung.

- DIN-Rail Gehäuse

- Einsatz im industriellen Temperaturbereich: -40 bis +85 Grad


-unterschiedlich zur Pixtend v2 -L-
- alle Ein-/Ausgangsfilter sind für eine Zykluszeit von 20kHz ausgelegt. 
Die Pixtend hat die meisten Filter, 2. Ordnung, auf 200-300Hz, womit 
eine Zykluszeit von max. 150 Hz möglich scheint.


- anstatt dem AVR 8bitter bei der Pixtend, ist ein Tandem aus ESP32 plus 
BIOS bei der Transformer-PLC für den Realtime Part zuständig. Der ESP32 
deswegen, weil die IEC-61499 Runtime, 4Diag FORTE, seit einiger Zeit auf 
dem ESP32 läuft. Es ist die ESP32 Variante mit 8MByte RAM und 16 MByte 
Flash verbaut.


- der Raspi und der ESP32 sind galvanisch vom Rest getrennt.


- die Transformer-PLC kann ohne Raspi stand-alone betrieben werden. Dank 
wired und wireless Ethernet auf dem ESP32 perfekt für verteilte 
Automatisierung mit 4Diag FORTE. Es können beliebig viele 
Transformer-PLC über Ethernet-Switche zu einem großen Netzwerk 
zusammengeschalten werden.


- die 16 x DI, 12 x DO, 6 x AI, 2+2 AO und 4 x GPIO sollen mit einer 
max. Zykluszeit von 20kHz gelesen/geschrieben werden. Die Relays nicht, 
die sind dafür zu langsam. Damit diese hohe Geschwindigkeit erreicht 
werden kann, ist der spezielle BIOS chip nötig. Der ESP32 alleine kann 
das nicht, wenn das wired Ethernet an der RMII angeschlossen ist, hat 
der ESP32 auch fast keine Pins mehr frei.


- analoge Signalerfassung: großer Wert wurde auf separate analoge 
Versorgungsspannung, mit ultra-low noise Reglern gelegt. 
Festspannungsregler vom Schlag 78xx rauschen zu stark, deshalb wurden 
LM317 und LM2940 verwendet. Die Analogsektion des Bios hat den noch 
rauschärmeren RT9193-33, sowie eine 0.1% initial accurate 
Referenzspannung (ADR5040) als Vref. Genaue Specs werde ich später 
nachreichen. Die 6 analogen Eingäge können mit max. 3x2 MSpS mit 12 bit 
erfasst werden, womit ein 32-faches oversampling möglich ist. Damit 
sollten netto 14-15 bit Auflösung drin sein.


- der ESP32 ist entweder per SPI (80MHz) an den Raspi angebunden, oder 
per wired/wireless Ethernet als FORTE Cluster-Node. Oder ganz stand 
alone, z.B. mit ESPHome. Sowohl der RasPi, wie auch der ESP32, haben ein 
I2C EEPROM als nicht-flüchtigen Speicher, Batteriepufferung für die 
Echtzeituhr und ext. Supervisor. Der ESP32 kann vom Raspi aus 
programmiert werden.


- mit dem Raspi wird CODESYS auf der Transformer-PLC laufen, dann ist 
das eine ganz klassische IEC-61131 Steuerung.


Kosten wird die Transformer-PLC 140 USD (ca. 130 Euro), incl. Gehäuse, 
jedoch OHNE Raspi. Für die 3 Erweiterungsslots(1x an ESP, 2 x an Raspi) 
wird es dann in Zukunft entsprechende Module geben (Thread, Zigbee? 
FD-CAN). Schaltpläne werden zur Crown Supply Kampangie veröffentlicht, 
dann gibt es auch erst Messergebnisse von Prototypen.


Hat noch jemand Ideen, was heutzutage für Home- und 
Industrieautomatisierung unbedingt vorhanden sein muss, und in der 
bisherigen Beschreibung noch nicht erwähnt?

[Harald K. (kirnbichler)]

Revo B. schrieb:
> Schaltpläne werden zur Crown Supply Kampangie veröffentlicht

Falsches Forum. "Projekte & Code" dient nicht der Anpreisung 
kommerzieller Produkte.

[Andreas M. (amesser)]

Revo B. schrieb:
> - die 16 x DI, 12 x DO, 6 x AI, 2+2 AO und 4 x GPIO sollen mit einer
> max. Zykluszeit von 20kHz gelesen/geschrieben werden. Die Relays nicht,

Was soll das bringen wenn der eigentlich Steuerungscode auf dem 
"langsamen" ESP32 (der so langsam gar nicht ist) läuft? Eingänge 10 mal 
lesen und davon 9x wegwerfen? Was willst du mit den 20kHz - 
Zeitungsdruckmaschinen steuern? In der Industrie sind 10ms Zykluszeit 
für verteilte Automatisierung Standard, das reicht für so ziemlich 
alles. Bei Prozessautomation kommen da nochmal ein bis zwei '0'en dran. 
Selbst für die meisten Motion-Control Sachen reichen 1ms aus.

Revo B. schrieb:
> Damit
> sollten netto 14-15 bit Auflösung drin sein.

Ganz sicher nicht wenn der ESP oder der PI ihr WLAN anschalten...

[Revo B. (michael_s23)]

Hallo Andreas,

es gibt sicher viele Anwendungen, bei denen 10ms Zykluszeit ausreicht. 
Aber es gibt auch anspruchsvollere Anwendungen, z. B. Servo-Steuerungen, 
Mehrarm-Robotersteuerungen usw.

Ethercat wurde z.B. für genau solche anspruchsvollere Anwendungen 
entwickelt. Es gibt also sehr wohl solche Anforderungen. Hier eine 
Application Note von TI: "Motor drive applications normally use a 20-kHz 
cycle time and a maximum of eight axes. "
https://www.ti.com/lit/an/snoaa89/snoaa89.pdf?ts=1711027787313&ref_url=https%253A%252F%252Fwww.google.com%252F

Die Tranformer-PLC kann aber natürlich auch jede längere Zykluszeit, 
einfach den Parameter auf 10 Hz setzten, fertig.

"Ganz sicher nicht wenn der ESP oder der PI ihr WLAN anschalten..." ich 
hab doch geschrieben, dass der ESP und der Pi galvanisch getrennt sind 
von der analog Sektion. Die haben gal. getrennte Netzteile. Da ist es 
völlig wurscht, ob die das WLAN anschalten oder sonst was machen. Der 
BIOS chip, der die analoge Sektion macht, hat sauber getrennte analoge 
und digitale Stromversorgungen, mit ultra-low noise linear Reglern, und 
den Sternpunkt der Masse am AGND pin. TI hat eine Application note, die 
das genau so macht, und 16 bit rauschfreie ADC bits erziehlt.

Wegen der 20kHz: ich hab an einer Anwendung gearbeitet, die Schwinungen 
eines Prüflings mit 50kSpS abgetastet hat, mit einer Beckhoff PLC. Die 
Beckhoff Analog-Module haben 50kSpS als max. Abtastfrequenz. Wenn Du 
eine FFT mit Resonanzanlyse machst, sind selbst 50kSpS nicht so viel. 
Per EtherCat kommt das auch in Echtzeit in den Controller. Wie gesagt, 
es gibt viele Anwendungsfälle.

[Andreas M. (amesser)]

Revo B. schrieb:
> Servo-Steuerungen,
> Mehrarm-Robotersteuerungen usw.

Und das ist die Zielgruppe Deiner Steuerung? Wie schließe ich denn den 
so einen 3-Phasen Inverter und den Encoder des Servos an Deine Steuerung 
an? Und das soll man dann irgendwie anprogrammieren?

Sowohl bei Ethercat Steuerungen als auch bei Simotion ist die gesamte 
Regelschleife in einen fertigen Baustein gekapselt. Das einzige was das 
IEC Programm da noch machen kann ist die Position, Geschwindigkeit oder 
Regelparameter vorgeben. Die Regelschleife selbst läuft entweder als 
Teil des PLC Systems oder direkt im Antriebsumrichter selbst.

Und wie genau soll denn die IEC-61499 Anwendung, die ja auf dem nach 
Deinen Worten "langsamen" ESP32 läuft von dem schnellen "Bios" (Ich 
würde da einen anderen Namen wählen) profitieren an? Wie soll da dann 
20KHz Zykluszeit erreicht werden?

Revo B. schrieb:
> ich
> hab doch geschrieben, dass der ESP und der Pi galvanisch getrennt sind
> von der analog Sektion.

Und die galvanische Trennung verhindert das sich die Funkwellen des 
ESP32 und Raspi in Richtung deiner Analogsektion ausbreiten?

Revo B. schrieb:
> Die
> Beckhoff Analog-Module haben 50kSpS als max. Abtastfrequenz. Wenn Du
> eine FFT mit Resonanzanlyse machst, sind selbst 50kSpS nicht so viel.
> Per EtherCat kommt das auch in Echtzeit in den Controller. Wie gesagt,
> es gibt viele Anwendungsfälle.

Diese Beckhoff-Module  mit einer Auflösung von 16 Bit haben lt. 
Datenblatt eine Genauigkeit von 0.5% Von den 16 Bit bleibt also nicht 
viel übrig. Und schau mal genau hin, die kleinste Zykluszeit der EL3632 
ist z.B. 10kHz. Bei 50kHz Sample-Rate überträgt die EL3632 fünf 
Messwerte pro Zyklus am Stück.

[Thomas W. (goaty)]

Revo B. schrieb:
> Crown Supply Kampangie

Eine was?
Crowd-Funding Kampagne

[Revo B. (michael_s23)]

oh, typo. Ja, natürlich eine Crowd Supply Kampagne. Auf 
https://www.crowdsupply.com/

[Revo B. (michael_s23)]

> "Und das ist die Zielgruppe Deiner Steuerung?"

Alle die mehr als 10ms Intervalzeiten brauchen. Und auch die, die 
weniger als 10ms brauchen, und nicht 458,15 EUR für eine Kontron Pixtend 
zahlen möchten, sondern für 1/4 des Preises was Vergleichbares bekommen.

Und dann die, die auf IEC 61499 umsteigen möchten. Oder die in 
C/C++/Python direkt den ESP32 programmieren möchten, ganz ohne Raspi.

Die ESPHome Nutzer, die ihre Hausautomatisierung machen.

Arduino-Benutzer, denen die Arduino Opta für 161,00 EUR nicht genug IOs 
bietet.

> "Wie schließe ich denn den so einen 3-Phasen Inverter und den Encoder des Servos 
an Deine Steuerung
an?"

unendliche Möglichkeiten: z. B. 4-20mA Eingang für Position. und 4-20mA 
Ausgang als Steuersignal. Oder digitales Ein/Aus. Oder 0-10V 
Ein/Ausgänge. Oder 0-5V. Oder per CAN Bus. Oder Modbus?

Ein EtherCat Anbindung wäre noch zu implementieren. Leider sind die 
SPI-EtherCat ICs aktuell nicht leiferbar, sobald sich die Situation 
verbessert, werde ich ein Erweiterungsmodul für die Transformer-PLC 
machen.

Es gibt übrigens nicht nur 3-Phasen Inverter auf der Welt. Ich musste in 
der Vergangenheit auch pneumatische Regelschleifen machen, wo 
Drucksensoren und Regelventile per 4-20mA Stromschleifen angebunden 
waren.

> "Und das soll man dann irgendwie anprogrammieren?"

Das macht man i.d.R. mit einer PI/PID Regelschleife, obwohl auch da 
viele Wege zum Ziel führen. Kleiner Tipp: google mal mach "PID Function 
Block", da kannst Du lernen, wie man PID Regelschleifen aufbaut.

> Und wie genau soll denn die IEC-61499 Anwendung, die ja auf dem nach
> Deinen Worten "langsamen" ESP32 läuft von dem schnellen "Bios" (Ich
> würde da einen anderen Namen wählen) profitieren an?

Nein, der ESP32 ist nicht langsam. Ganz im Gegenteil, ausführen von 
Logicblöcken macht die ESP32 in hervorragender Geschwindigkeit. Dank 
240MHz Dual Core, kann sich ein Kern nur um die Kommunikation (Ethernet 
oder SPI zum Raspi) kümmern, während der zweite Core die IEC-61499 
RT-Kern ausführt. Was der ESP32 nicht (gut) kann, ist analog. Auch hat 
der ESP32 nicht genug Pins, um die 52 IO Klemmen anzusteuern. Die 
klassischen IO Expander sind zu langsam, und haben auch kein analog. 
Deshalb das Bios.

> Wie soll da dann 20KHz Zykluszeit erreicht werden?

Durch cleveres Engineering. Die 240MHz des ESP32 Kerns, geteilt durch 
20k, sind 12.000 MCU Zyklen je PLC Zyklus. Die Daten von dem BIOS werden 
per DMA eingetaktet/rausgeschoben, die ESP32 muss lediglich die DMA 
Puffer füllen/lesen und die Logik berechnen. Lt. einer App Note von 
Microchip braucht ein PID-Algo auf deren dsPIC 13 DSP-Zyklen. Also genug 
Dampf unter der Haube.

> Und die galvanische Trennung verhindert das sich die Funkwellen des
> ESP32 und Raspi in Richtung deiner Analogsektion ausbreiten?

Die galvanische Trennung verhindert, dass leitungsgebundene Störungen 
sich auf die analog-Sektion ausbreiten.

Abgestrahlte Störungen können nur durch Schirmung unterdrückt werden, 
WENN sie in einem Frequenzbereich sind, der im Messbereich liegt. Das 
WLAN liegt bei 2.45GHz, und deren Oberwellen. Die werden durch den 
100kHz Eingangsfilter aufgefressen.

Selbst wenn der Raspi und ESP32 Wifi anbieten, warum sollte man für eine 
Industriesteuerung Wifi benutzen? Dafür hat die Transformer-PLC 
kabelgebundenes Ethernet.

> Diese Beckhoff-Module  mit einer Auflösung von 16 Bit haben lt.
> Datenblatt eine Genauigkeit von 0.5% Von den 16 Bit bleibt also nicht
> viel übrig.

Du bringst hier Auflösung und Genauigkeit durcheinander. Die 
unkalibrierte, absolute Genauigkeit, über den Temperaturbereich und die 
Lebensdauer, ist da 0.5% (Bei der Transformer-PLC 0.1%, TBD). Die 
Auflösung bleibt trotzdem 16 Bit. Wenn das Beckhoff-Modul kalibriert 
wird, oder Du den Offset-Fehler sonstwie rausrechnest, kannst Du auch 
die Genauigkeit entsprechend ausnutzen.

> Und schau mal genau hin, die kleinste Zykluszeit der EL3632
> ist z.B. 10kHz.

Ach, sie an. Es gibt also doch einen Markt für 10kHz Zykluszeit. Damit 
hast Du Deine Aussage "niemand braucht mehr als 100Hz Zykluszeit" selbst 
widerlegt.

[Andreas M. (amesser)]

Revo B. schrieb:
> unendliche Möglichkeiten: z. B. 4-20mA Eingang für Position. und 4-20mA
> Ausgang als Steuersignal. Oder digitales Ein/Aus. Oder 0-10V
> Ein/Ausgänge. Oder 0-5V. Oder per CAN Bus. Oder Modbus?

Und das muss mit 20 kHz passieren?

Revo B. schrieb:
> Das macht man i.d.R. mit einer PI/PID Regelschleife, obwohl auch da
> viele Wege zum Ziel führen. Kleiner Tipp: google mal mach "PID Function
> Block", da kannst Du lernen, wie man PID Regelschleifen aufbaut.

Die bei einer anständigen PLC in einem fertig auf den Motor abgestimmten 
Block bereits enthalten ist. Da implementiert niemand händisch einen 
PID.

Revo B. schrieb:
> Durch cleveres Engineering. Die 240MHz des ESP32 Kerns, geteilt durch
> 20k, sind 12.000 MCU Zyklen je PLC Zyklus. Die Daten von dem BIOS werden
> per DMA eingetaktet/rausgeschoben, die ESP32 muss lediglich die DMA
> Puffer füllen/lesen und die Logik berechnen.

Aha und in der Zeit wo der ESP auf den DMA wartet bleibt die Zeit für 
Ihn also stehen? Und jetzt komm mir nicht mit, das DMA und Verarbeitung 
parallel laufen, in dem Fall hast du nämlich keine "20kHz" sondern eher 
2*10KHz interleaved, weil du einen Zyklus Verzögerung bekommst.

Revo B. schrieb:
> Damit
> hast Du Deine Aussage "niemand braucht mehr als 100Hz Zykluszeit" selbst
> widerlegt.

Das habe ich so nicht geschrieben. Ich habe geschrieben, das 99% der 
Anwendungsfäll der Industrie es nicht brauchen und der kleine 
Heimautomatisierer der möglicherweise mit so einem Gerät was anfangen 
könnte sicher auch nicht.

Verstehe mich nicht falsch, ich finde Dein Projekt schon nett, 
allerdings sind das alles ziemliche Fantasiezahlen, bevor man sowas 
postuliert sollte man mehr als einen Schaltplan und ein noch nichtmal 
geroutetes PCB haben.

[J. S. (jojos)]

Wir machen mit (Soft)PLC auch schnelle Messwerterfassung/Verarbeitung 
und auch Bildverarbeitung und da werden auch kurze Zykluszeiten 
gebraucht.
Bisher mit X86 Hardware, für einfache Sachen reicht aber eventuell auch 
günstigere Hardware, da ist das Projekt schon interessant.
Arduino PMC habe ich als Alternative getestet, gefällt mir nicht. Vor 
allem weil die Arduino Experten den SWD Port für IO missbraucht haben.

[Revo B. (michael_s23)]

> Das habe ich so nicht geschrieben. Ich habe geschrieben, das 99% der
> Anwendungsfäll der Industrie es nicht brauchen und der kleine
> Heimautomatisierer der möglicherweise mit so einem Gerät was anfangen
> könnte sicher auch nicht.

Wenn Beckhoff seine Analog-Module auf 10kSpS auslegt, dann mach ich das 
auch. Wenn Beckhoff dafür Kunden hat, hab ich die auch. Die Welt ist 
groß, und die Anwendungen sehr verschieden.

> Und das muss mit 20 kHz passieren?

Warum nicht? Kann ja jeder einstellen, wie er möchte. Wessen Algorithmus 
nur 10 Hz braucht, kann das auch nehmen.

Du klingst wie Bill Gates: "Niemand wird je einen Computer mit mehr als 
640kB Ram brauchen". Das war lange vor Windows.

> Die bei einer anständigen PLC in einem fertig auf den Motor abgestimmten
> Block bereits enthalten ist. Da implementiert niemand händisch einen
> PID.

Die Welt ist größer als nur Motorsteuerungen. Kann auch eine Heizung 
sein. Oder eine pneumatische Ventilsteuerung. Oder was hydraulisches. 
Oder was ganz anderes. IEC-61499 wird z. B. bei (landwirtschaftlichen) 
Fahrzeugen eingesetzt.

In der IEC 61131 sind PI und PID Regler explizit erwähnt. Wird auch an 
jeder Schule unterrichtet. Ich sehe die Transformer-PLC als ideal für 
Schulen und Ausbildung. Zum praktischen Erlernen von PI und PID Reglern.

> Ich habe geschrieben, das 99% der
> Anwendungsfälle der Industrie es nicht brauchen

Wenn Robotik für Dich kein Thema ist, mag das so sein. Aber stell Dir 
mal einen 3-Achs Robotikarm vor: Mit 10ms Zykluszeit wird der recht 
holprig. Eine situationsabhängige Beschleunigungskurve geht viel besser 
mit 50us Zykluszeit. Ich weiss, Du programmierst keine PID, sondern 
nimmst nur "fertig auf den Motor abgestimmten Block". Für Deine Probleme 
gibt es halt schon fertig vorgerührte Lösungen. Aber ich bin sicher, 
dass es genügend Anwendungen gibt, wo eine spezifische PID selbst 
programmiert werden muss.

Robotik ist die Zukunft. Die 99% der Industrie werden bald auf Robotik 
umsteigen. Denke ich mal.

> Verstehe mich nicht falsch, ich finde Dein Projekt schon nett,
> allerdings sind das alles ziemliche Fantasiezahlen, bevor man sowas
> postuliert sollte man mehr als einen Schaltplan und ein noch nichtmal
> geroutetes PCB haben

Drum hab ich ja auch geschrieben im initialen Post: "Hat noch jemand 
Ideen, was heutzutage für Home- und Industrieautomatisierung unbedingt 
vorhanden sein muss, und in der bisherigen Beschreibung noch nicht 
erwähnt wurde?"

Wenn die Leiterplatte schon fertig geroutet, der Prototyp getestet und 
vermessen wurde, dann ist es vorbei. Ich habe
- Produktidee
- Anforderungskatalog / Spec Sheet
- Kostenkalkulation / Preisrahmen
- Bauteilverfügbarkeitsprüfung.

Leiterplatte routen kommt am Schluss.

Mich hätte interessiert, wie sehen die Leute die Wichtigkeit von
- EtherCat, SerCos, Profibus, PowerLink
- KNX, DALI, BACnet
- Single Pair Ethernet
- IO Link

ect sehen.

Durch das modulare Erweiterungskonzept können fast alle Schnittstellen 
nachgerüstet werden, WENN die mit den bestehenden Bussen (RMII, SPI, 
I2C, UART) angesprochen werden können. So kann ich z.B. ein EtherCat 
interface nachrüsten, weil es dafür per SPI ansprechbare Bausteile gibt. 
Bei SerCos oder Profibus bin ich mir nicht sicher. KNX, DALI, BACnet SPE 
würden auch gehen. Nutzt wer IO Link?

[Andreas M. (amesser)]

Revo B. schrieb:
> Wenn Robotik für Dich kein Thema ist, mag das so sein. Aber stell Dir
> mal einen 3-Achs Robotikarm vor: Mit 10ms Zykluszeit wird der recht
> holprig.

Ja, und die paar Motoren und Encoder mit Kurvensteuerungen sind genau 
der Anwendungsfall der in die 1% fällt die eben nicht mit 10ms oder 
langsamer abzudecken sind. Derartige Motorsteuerungen machen aber den 
kleinsten Teil des Automatisierungsmarktes aus. Das meiste was so ne PLC 
zu bedienen hat sind simple Schalter, Sensoren und einfache 
Motorschütze. Und davon hat selbst der nackte Roboterarm 10 mal mehr von 
als Motoren. Und dafür brauchts keine 1ms und erst recht keine 100µs.

Revo B. schrieb:
> Robotik ist die Zukunft. Die 99% der Industrie werden bald auf Robotik
> umsteigen. Denke ich mal.

Das ist, da wo sinnvoll, schon längst passiert. Funktioniert aber eben 
nur bei Massenfertigung vernünftig. Ich erinner mich noch gut daran als 
vor ein paar Jahren jeder von der voll automatisierten Fertigung bis 
Losgröße "1" geschwafelt hat. Davon ist nicht viel übrigen geblieben, 
denn ne andere Farbe aufs Gehäuse sprühen ist eben nicht Losgröße "1" 
sondern nur ein kleiner Fertigungsparameter. Die Roboter programmieren 
sich halt dummerweise nunmal nicht von selbst. Inzwischen ist man da 
wieder einen Schritt zurück und will es nun mit "kollaborativen" 
Robotern probieren. Da muss sich aber noch viel tun, die Interaktion 
zwischen so einem Roboter und dem Menschen ist bislang eher noch sehr 
hakelig...

Revo B. schrieb:
> - EtherCat, SerCos, Profibus, PowerLink
> - KNX, DALI, BACnet
> - Single Pair Ethernet
> - IO Link

SerCos ist eine im Absterben befindliche Nischenlösung, selbst bei 
Rexroth. Profibus wird durch Profinet ersetzt, bei Siemens verschwinden 
die eingebauten Profibus Schnittstellen Stück für Stück. Powerlink hat 
ne wechselhafte Geschichte, erfunden von B+R, was inzwischen zu ABB 
gehört. Hat ebenfalls kaum mehr Marktanteil und ist von der Technologie 
her - naja "Hub, Halb-Duplex".

KNX, DALI & BACnet ist Hausautomatisierung, habe ich wenig mit zu tun, 
ich denke aber KNX wird es noch sehr lange geben.

Single Pair Ethernet ist gerade im kommen, wird auf kurz oder lang viele 
Zwei-Draht Sensoren da ersetzen wo es mit IO-Link nicht geht, weil es 
viel mehr kann, aber bestehende Verkabelung weitergenutzt werden kann. 
Typischeranwendungsfall ist einen Sack voll 4-20mA Sensoren durch SPE 
basierte zu ersetzen, da wo vorher die Signale der Sensoren gesammelt 
wurden kommt ein Mehrport PoE SPE/APL Switch hin und von da zur PLC.

IO-Link ist inzwischen fertig entwickelt. Die Produkte sind am Markt. 
Mal sehen wie sich der Markt für kleine Sensoren zwischen IO-Link und 
SPE aufteilt. SPE ist aus Sensorsicht komplexer umzusetzen.

Aktuell in Entwicklung sind TSN basierte Netzerksysteme, da wird aber 
noch viel Zeit vergehen bis das einsatzreif ist.

[Revo B. (michael_s23)]

Danke Andreas, für Deine umfangreiche Einschätzung.