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?
:
Verschoben durch Moderator
Revo B. schrieb: > Schaltpläne werden zur Crown Supply Kampangie veröffentlicht Falsches Forum. "Projekte & Code" dient nicht der Anpreisung kommerzieller Produkte.
:
Bearbeitet durch User
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...
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.
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.
> "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.
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.
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.
:
Bearbeitet durch User
> 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?
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.
Danke Andreas, für Deine umfangreiche Einschätzung.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.