Profinet - wer kennt sich damit aus?

Hallo Martin,

falsche Forum, bei http://www.sps-forum.de/ bist du gut aufgehoben.

Ich kenne mich ein Wenig aus, fragt einfach, vielleicht kann ich helfen.

Anwender oder Entwickler? Schwierigkeiten beim theoretischen 
Verständnis?

Man kann dir nicht sagen ob du Hilfe erwarten kannst wenn du nicht mal 
im Ansatz das Problem beschreibst.

Dennis S. schrieb:
> Anwender oder Entwickler? Schwierigkeiten beim theoretischen
> Verständnis?

Alles zusammen.

> Man kann dir nicht sagen ob du Hilfe erwarten kannst wenn du nicht mal
> im Ansatz das Problem beschreibst.

Der Aufbau ist folgender:

Ein total beschissener Univeral Robots Roboter (Gott ich sag euch, wenn 
Ihr das irgendwie vermeiden könnt wenn so eine Anschaffung bei euch ins 
Haus steht: Nehmt was gescheides!) der bisher nur MODBUS TCP konnte. 
Architektur ist: Server steuert über Modbus den UR-Roboter sowie zwei 
weitere Prüfstände, die alle zusammenhängen.

Jetzt kam am Roboter ein Zukaufteil dazu (Greifer) der nur IO-Link kann. 
Der Vertreter sagte IO-Link wäre kein Problem, weil der UR Roboter mit 
der Firmwareupdate dann auch Profinet unterstützt.

Also einen IO-Link-Master<>Profinet Adapter dazugekauft, und jetzt 
festellen müssen, dass er UR, der sich damit rühmt, eine SPS zu haben, 
nur ein Profinet Client ist und keine Masterfunktionalität hat. Steht 
nur leider nirgendwo beschrieben weil selbst nach einem Monat im Manual 
vom UR-Roboter kein Sterbenswörtchen von Profinet erwähnt wird. Support 
gibt es keinen in Deutschland, das läuft nur über die Vertriebspartner 
und jetzt - tada - die haben keinen blassen Schimmer, freuen sich aber 
natürlich darüber, dass sie jetzt erfahren, dass der UR auch Profinet 
kann...

Der Roboter soll direkt den Greifer steuern können, weil er ja selbst 
die Hoheit über seine eigene Hardware haben soll. Aber damit er das 
kann, muss ich jetzt irgendwie den Profinet Slave auf den IO-Link 
Greifer bekommen. Scheinbar hilft mir der IO-Link-Master nicht in dem 
Maße, wie ich mir das erhofft habe.

Und da suche ich jetzt nach Ideen, Anregungen oder Aufklärung.

Gibt es keine Slave<->Slave Kommunikation bei Profinet? Oder anders 
gefragt: Gibt es keine Profinet-Master, die man nur ins Netz hängen 
kann, damit halt irgendein Master da ist? Ich kann doch nicht irgendeine 
SPS verbauen?!

Hm...
Ok als ich damit gearbeitet hatte (schon etwas her), hatte ich nur 
Luxus! Probleme waren alles anders als deine.

Martin S. schrieb:
> dass er UR, der sich damit rühmt, eine SPS zu haben,
> nur ein Profinet Client ist und keine Masterfunktionalität hat.

Bist du hier 100% sicher? wenn ja, dann geht meine Meinung nach nicht, 
der Robi braucht eine Masterfunktion damit er mit seine "externe" 
Peripherie klar kommt.

Was ist mit dem einge E/As? von Robi? eine Lösung wäre die E/As von 
Greifer direkt an der Kontroller von Robi anklemmen, wenn keine freie 
E/A mehr gibt dann MUSS 100% E/A Karten von Herteller von Robi geben.

Martin S. schrieb:
> Server steuert über Modbus den UR-Roboter sowie zwei
> weitere Prüfstände, die alle zusammenhängen.

Server? hast du kein SPS? andere Lösung wäre, die E/As von Greifer in 
SPS bzw. Server bearbeiten (also IO Link an SPS/Server) dann an Robi 
weiter sagen was er machen soll.

Martin e. C. schrieb:
> Hm...
> Ok als ich damit gearbeitet hatte (schon etwas her), hatte ich nur
> Luxus! Probleme waren alles anders als deine.
>
> Martin S. schrieb:
>> dass er UR, der sich damit rühmt, eine SPS zu haben,
>> nur ein Profinet Client ist und keine Masterfunktionalität hat.
>
> Bist du hier 100% sicher? wenn ja, dann geht meine Meinung nach nicht,
> der Robi braucht eine Masterfunktion damit er mit seine "externe"
> Peripherie klar kommt.

Ja, wundert mich auch. Da steht allerdings im entsprechenden Menü 
"Profinet Device". Da bleibt er hängen, weil er keine kommunikation zum 
Master aufbauen kann :-/

> Was ist mit dem einge E/As? von Robi? eine Lösung wäre die E/As von
> Greifer direkt an der Kontroller von Robi anklemmen, wenn keine freie
> E/A mehr gibt dann MUSS 100% E/A Karten von Herteller von Robi geben.

Dann hätten wir keinen IO-Link Greifer nehmen dürfen. Allerdings ist er 
mit E/A-Gesteuert auch ziemlich "dumm", da die ganze Repzeptverwaltung 
dann fehlt. Und eine UR-kompatible Version vom Greifer, die dann ein 
Plugin für die Oberfläche des Roboters hat, kommt erst jetzt irgendwann 
raus.

> Martin S. schrieb:
>> Server steuert über Modbus den UR-Roboter sowie zwei
>> weitere Prüfstände, die alle zusammenhängen.
>
> Server? hast du kein SPS?

Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar 
nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu 
machen. Wir haben keine zeitkritischen Abläufe, der Server gibt über 
Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der 
allerdings in der Steuerung des Roboters hinterlegt ist.

Normalerweise sind diese UR ja auch als stand-alone Geräte konzipiert. 
Dass dann aber elementare Steuerfunktionen fehlen hätte ich nicht 
erwartet... wobei ich von dem Teil inzwischen gar nichts mehr erwarte. 
Hätten wir doch nur Kuka oder ABB oder Mitsubishi oder .... genommen. Da 
kostet das Teil zwar in der Anschaffung das Doppelte, dafür habe ich ein 
technisches High-end Gerät mit Toleranzen um den Faktor 10 besser und 
wirklich extrem guten Support, der auch bei der Projektierung hilft. So 
versuchen wir jetzt alles von der Pike auf selbst uns beizubringen. 
Worin das endet, sieht man ja jetzt...

> andere Lösung wäre, die E/As von Greifer in
> SPS bzw. Server bearbeiten (also IO Link an SPS/Server) dann an Robi
> weiter sagen was er machen soll.

So haben wir es jetzt mit dem alten Greifer. Aber das ist extrem 
umständlich, weil man fragmentierten Code bekommt. Daher wollte ich ja 
auch den Greifer am Roboter haben.

Es ist in der Industrie üblich, das Roboter sich extern als Device 
darstellt. Dieses kann dann von einer übergeordneten Steuerung 
angesprochen werden und so quasi mehrere Roboter von einer Steuerung 
koordiniert werden. Vermutlich unterstützt das Ding deswegen nur Device. 
Die Roboter haben dann meistens ein internes Bus-System um Ihre eigenen 
Peripherien zu steuern. Das kann z.b. auch ein Profinet System sein, bei 
dir ist es wohl Modbus. Wenn ich das richtig verstehe gehört der Greifer 
ja zum Roboter selbst, ist dann Topologisch eigentlich eher am Internen 
Bus des Roboters anzusiedeln. Bekommst Du überhaupt die Steuerbefehle 
für den Greifer über das Device Interface des Roboters nach draußen? 
Möglicherweise wäre es sinnvoller gewesen einen Modbus auf IO-Link 
Adapter zu nehmen, weis aber nicht ob es sowas gibt.
Was Du machen könntest wäre eine billige Profinet Steuerung zu kaufen, 
mit dieser den Roboter und den Profinet-IO-Link Adapter anzusprechen und 
dann die Steuerung die Daten von dem Roboter auf den Adapter spiegeln zu 
lassen. Dafür reicht vermutlich jede Siemens Steuerung aus.
An Deiner Stelle hätte ich eine Siemens CPU mit Rückwandbus genommen 
(Die kann Profinet Master) und and den Rückwandbus ein IOLink Master 
Modul gesteckt.

https://mall.industry.siemens.com/mall/de/WW/Catalog/Product/6ES7510-1DJ01-0AB0

https://mall.industry.siemens.com/mall/de/WW/Catalog/Product/6ES7137-6BD00-0BA0

(Ich arbeite übrigens nicht bei Siemens, mache aber den ganzen Tag 
Profinet)

Hallo Andreas,

vielen Dank für Deinen Rat.

Problem ist, dass diese Modbus<->IO-Link Geschichten wohl nicht das 
Gelbe vom Ei sein sollen. Man macht schlussendlich einen riesen Spagat.

Das nächste Projekt wird eine SPS bekommen - so schlau ist man 
offensichtlich schon und auch dieses wird umgestellt werden. Man will 
jetzt halt erstmal produzieren können, sonst liegt der Aufbau noch 
länger brach. Doch wie heißt es so schön: Nichts hält länger als ein 
Provisorium.

Aber um das nochmal zu verdeutlichen, wie das normalerweise abläuft:

- Zwei Profinet-Devices dürfen nur über einen Switch miteinander 
verbunden werden, es sei denn, sie haben einen integrierten Switch.

- Im Profinet braucht es immer einen Master/Server

- Die Parametrisierung von Profinet-Devices läuft immer über einen 
Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte 
+ Supervisor-Software?)

- Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt 
(vorher haben sie ja auch noch gar keine IP, oder?)

- Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal 
nichts von denen. Der Server muss also die Topologie kennen, oder?

- Die Datenübertragung zwischen Devices wird über den Server/Master 
abgearbeitet, oder?

Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen? 
Quasi eine Master+Supervisor-Software?

Martin S. schrieb:
> - Die Parametrisierung von Profinet-Devices läuft immer über einen
> Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte
> + Supervisor-Software?)

Kommt etwas drauf an, was du mit Parametrierung meinst.
Die Taufe (Zuweisung des Profinet-Stationsnamens) und die Auswahl der 
Prozessdatenmodule erfolgt im Regelfall über die Projektierungsumgebung 
deiner Steuerung (Step7/TIA bei Siemens, Twincat bei Beckhoff, etc.).
Je nach Gerät kann die Steuerung während Betriebs dann aber natürlich 
noch Geräteparamter ändern (über die Busverbindung).

> - Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt
> (vorher haben sie ja auch noch gar keine IP, oder?)

Profinet-Geräten wird keine IP zugewiesen, nur ein Stationsname.
Die IP bekommen die Geräte dann während des Profinet-Startups von Master 
zugewiesen.

> - Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal
> nichts von denen. Der Server muss also die Topologie kennen, oder?

Ne, Topologie muss nicht bekannt sein. Der Bus kann gescannt werden, um 
die Geräte zu finden.

> - Die Datenübertragung zwischen Devices wird über den Server/Master
> abgearbeitet, oder?

Was du mit (direkter) Datenübertragung zwischen Devices/Slaves meinst 
wird in der Feldbustechnik im allgemeinen Querverkehr genannt.
Wie das bei PN aber genau aussieht weiß ich momentan nicht.

> Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen?
> Quasi eine Master+Supervisor-Software?

Ja, es Profinet-Master auch in Software von diversen Herstellern.

Zu den Begrifflichkeiten:
Profinet ist keine Master/Slave-, sondern ein Producer-Consumer-System 
: Beim Hochlauf übermittelt der IO-Controller den Devices die 
Konfiguration die vorher im Engineering-Tool festgelegt wurde. Dazu 
gehört zum Beispiel der Stationsaufbau (bei modularen Devices) sowie die 
SendCycle. Nach dem ApplicationReady von seiten des Devices arbeitet das 
System autark. Es gibt kein Token oder Polling oder 
Request/Response-Verfahren währed des Prozessdatenaustauschs.

Ein Datenquerverkehr zwischen den Devices ist möglich wird aber nicht 
immer unterstützt. Stichwort zum Suchen ist MCR.

Der Supervisor hat im Wesentlichen die gleichen Funktionen wie ein 
Controller. Einige wenige Unterschiede gibt es beim gleichzeitigen 
Zugriff auf ein Device.

IO-Devices haben durchaus eine IP-Adresse und bekommen diese häufig 
(aber nicht ausschließlich) vom Controller beim Startup zugewiesen. Auch 
dies ist im Engineering-Tool einstellbar. Der NameOfStation dient der 
Adressauflösung und unter anderem der Nachbarschaftserkennung via LLDP.

Da ich Robotik gelesen habe: eine alternative Startup-Form ist 
Fast-Startup bei der nach AIDA-Empfehlung nach 500ms ein Ausgang 
gesetzt werden können soll.

Gruß
Dennis

Martin S. schrieb:
> Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar
> nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu
> machen.
> Wir haben keine zeitkritischen Abläufe, der Server gibt über
> Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der
> allerdings in der Steuerung des Roboters hinterleg

Ich hatte bis jetzt in diese konstellation nie gehabt/gehört, natürlich 
ist alles möglich, besonders an der Uni's wird ähnliches gemacht und 
getestet ob es sinn macht ist wieder anders. So eine "eventuelle" 
günstiger Lösung kommt am Ede viel teuer, da bei Erweiterungen nicht 
flexibel ist.

Vielleichts kommst du jetzt auf ein SPS nicht herum, wäre eventuell 
günstiger als ers alles mögliche zu probieren.
In diesem Fall muss man sicher sein dass dein Robi oder die Profinet 
Karte von Robi sowie die IO Link Greifer von SPS problemlos angesprochen 
werden können (liegen die GSD Dateien vor?), dann nimmst du beide 
Teilnehmer in SPS und schiebst du die Daten zwischen Robi und Greifer 
hin und her.

Dominik S. schrieb:
> Ne, Topologie muss nicht bekannt sein. Der Bus kann gescannt werden, um
> die Geräte zu finden.

Bei paar Teilnehmer nicht, bei mehrere macht natürlich sinn da die 
Telegramme sauber zu jeder Teilnehmer kommen, bei Zeit kritische 
Anwendungen sowie so.

Martin e. C. schrieb:
> Bei paar Teilnehmer nicht, bei mehrere macht natürlich sinn da die
> Telegramme sauber zu jeder Teilnehmer kommen, bei Zeit kritische
> Anwendungen sowie so.

Falls es um PROFINET geht ist das so nicht richtig.. die Sende- und 
Empfangszeiten werden werden im ConnectFrame vom Controller an die 
Devices gegeben. Erst bei IRT (also RTC-Class 3) ist die Topologie 
wirklich wichtig. Aber das ist für den TO ja sowieso nicht relevant.

Gruß
Dennis

Martin e. C. schrieb:
> Martin S. schrieb:
>> Nein. Wir haben keinen SPSler, von der Zeitarbeitsfirma kam wirklich gar
>> nichts brauchbares also wurde entschlossen, die Steuerung mit Labview zu
>> machen.
>> Wir haben keine zeitkritischen Abläufe, der Server gibt über
>> Modbus nur dem UR die Anweisung einen Programmblock auszuführen, der
>> allerdings in der Steuerung des Roboters hinterleg
>
> Ich hatte bis jetzt in diese konstellation nie gehabt/gehört, natürlich
> ist alles möglich, besonders an der Uni's wird ähnliches gemacht und
> getestet ob es sinn macht ist wieder anders.

Wie macht man das dann typischerweise? Das Problem ist hier schlichtweg, 
dass man für den UR keine Leute bekommt. Also müssen wir alles selbst 
machen und uns fehlen auch jegliche Erfahrungswerte.

Wie wird es denn sonst gemacht?

> So eine "eventuelle"
> günstiger Lösung kommt am Ede viel teuer, da bei Erweiterungen nicht
> flexibel ist.

Wer hätte das gedacht? Also ich hab sowas "nie prophezeit"... Ich treffe 
halt die Entscheidungen nicht, sonst wäre es ganz anders gelaufen.

> Vielleichts kommst du jetzt auf ein SPS nicht herum, wäre eventuell
> günstiger als ers alles mögliche zu probieren.
> In diesem Fall muss man sicher sein dass dein Robi oder die Profinet
> Karte von Robi sowie die IO Link Greifer von SPS problemlos angesprochen
> werden können (liegen die GSD Dateien vor?), dann nimmst du beide
> Teilnehmer in SPS und schiebst du die Daten zwischen Robi und Greifer
> hin und her.

Genau das war der Plan - nur ohne SPS. Leider scheiterte er.

Ich muss nochmal Rückfrage mit Zimmer halten, die wollten einen reinen 
UR-Greifer auf den Markt bringen. Vllt. hat sich da ja mittlerweile was 
getan.

Martin S. schrieb:
> Wie macht man das dann typischerweise? Das Problem ist hier schlichtweg,
> dass man für den UR keine Leute bekommt. Also müssen wir alles selbst
> machen und uns fehlen auch jegliche Erfahrungswerte.
>
> Wie wird es denn sonst gemacht?

Ich hatte nur mit Automobil Industrie zu tun gehabt und obwohl auch viel 
viel geforscht wird, ist Typischerweise fast jede konstellation so:

Ein SPS (Master) und jeder menge Teilnehmer (Slaven), entspricht 
Stationen, Roboter usw.
Ein Roboter ist Slave von SPS aber Master von seine Teilnehmer wie z.B. 
Greifer, Zangen, Kappenfräser, etc. Sehr selten aber möglich waren 
Greifer (E/A Module) Slaves von SPS.

Das alles Unabhängig von Bussystem.
Die "übliche" Robotern und SPS'en können Profibus und Profinet.

Hallo Martin,

war leider etwas abwesend. Zusammenfassend zu deinen Fragen, es gab ja 
schon eine ganze Menge richtig Antworten

Martin S. schrieb:
> Aber um das nochmal zu verdeutlichen, wie das normalerweise abläuft:
>
> - Zwei Profinet-Devices dürfen nur über einen Switch miteinander
> verbunden werden, es sei denn, sie haben einen integrierten Switch.

Genau, ein Hub ist in einem Profinet Netzwerk nicht zulässig. (Die 
Geräte erkennen das und verweigern den Datenaustausch). Die allermeisten 
Profinetgeräte haben jedoch einen Integrierten Switch mit mindestens 
zwei Ports.

> - Im Profinet braucht es immer einen Master/Server

Genau. Nur ein Master (Im Profinet Sprachgebrauch Controller - Master 
/Slave wollte man tatsächlich wegen der Nähe der Begriffe zu Sklaverei 
nicht verwenden) kann aktiv eine Verbindung zu einem Slave (Bei Profinet 
"Device") aufbauen. Dieser Controller überträgt beim Verbindungsaufbau 
sämtliche Parameter in das Gerät. (Bei jedem Hochlauf erneut)

> - Die Parametrisierung von Profinet-Devices läuft immer über einen
> Supervisor. (Wie sieht der aus? Ein stink normaler PC mit Netzwerkkarte
> + Supervisor-Software?)

Nein. Die Parameter die ein Gerät benötigt werden im Controller 
gespeichert. Diese werden dann beim Hochlauf vom Controller in das 
Device übertragen. Das einzige was man machen muss ist die sogenannte 
Gerätetaufe. D.h. die Bus Addresse des Profinet-Gerätes wird im Gerät 
permanent gespeichert ( so das bei Strom aus/an die addresse erhalten 
bleibt). Taufe deswegen, weil bei Profinet die Addresse des Geräts der 
Stationsname ist. Dafür bietet dann meist jeder Controllerhersteller ein 
eigenes kleines Tool an, man kann mit jedem solchen Tool jedes Profinet 
Device taufen, da das Protokoll standardisiert ist. Achtung: Neben dem 
Stationsnamen haben Profinet Geräte auch noch eine IP Addresse. Diese 
wird normalerweise jedoch vom Profinet Controller beim Hochlauf mit 
eingestellt.

Das was Du mit Supervisor meinst, heist bei Profinet "Engineering 
Software". Mit dieser nimmt man einmalig sein System in Betrieb, 
programmiert meist die PLC/Controller. Danach benötigt man diese nicht 
mehr, höchstens um mal Fehlerdiagnose zu machen. z.B. Step 7/TIA Portal, 
3S Codesys (wobei das auch selbst eine PLC sein kann), PC Worx. 
(Supervisor gibt es bei Profinet übrigens auch, das ist ein Controller 
mit speziellen Rechten)

> - Erst wenn die Devices parametrisiert sind, arbeiten sie überhaupt
> (vorher haben sie ja auch noch gar keine IP, oder?)

Im Prinzip ja. Der Hochlauf ist in mehrer Phasen aufgeteilt:
- Zuweisung IP Addresse
- Abgleich Soll/Ist Konfiguration, d.h. der Controller sendet was er im 
Device erwartet, und das Device vergleicht dass mit seiner 
Ist-Konfiguration und meldet eventuell Unterschiede
- Der Controller überträgt alle Parameter an das Device (z.B. ADC 
Wertebereiche, Kurzschlussbegrenzungswerte....)
- Das Device wendet die Parameter an und Signalisiert "application 
ready"
- Danach beginnt dann der Prozessdatenaustausch

> - Hängen jetzt die Devices am Bus, dann weiß der Server ja erstmal
> nichts von denen. Der Server muss also die Topologie kennen, oder?

Nein, der Controller muss nur die Namen der Geräte kennen. Wo die Geräte 
physikalisch verbunden sind ist erst mal egal, dae in ganz normales 
ethernet netzwerk aufgebaut wird. Man kann problemlos PCs mit 
anschließen oder sogar PC Netzwerkverkehr durch die Geräte hindurch 
transportieren. (Wenn man synchrones Profinet machen will gibt es da 
allerdings ein paar Einschränkungen)

> - Die Datenübertragung zwischen Devices wird über den Server/Master
> abgearbeitet, oder?

Beim Profinet sendet jeder Teilnehmer aktiv seine Daten zum Empfänger. 
Welche Daten zu senden sind und wohin diese zu senden sind wird vom 
Controller beim Hochlauf in das Device parametriert. Der Empfänger der 
Daten hat typischerweise ein Timeout mit dem er den Sender überwacht. 
Prinzipiell gibt es auch möglich Daten zwischen zwei Devices 
auszutauschen, jedoch können das nur wenige Devices. Aber selbst bei 
diesem Szenario benötigt man einen Controller, dieser muss nämlich 
beiden Devices sagen das sie miteinander sprechen sollen.

> Gibt es auch die Möglichkeit, den Master in Software laufen zu lassen?
> Quasi eine Master+Supervisor-Software?

Prinzipiell kann man einen Profinet Controller auch in Software auf 
einem PC laufen lassen, da es eben ganz normales Ethernet ist. 
Allerdings muss man sich hier Gedanken über Echtzeit machen, damit der 
PC die Telegramme schnell genug generiert. (Kleinster Profinet Sendtakt 
ist 4 ms, den kann man nochmals untersetzen, das können aber nicht alle 
Devices; Der Windows-Scheduler hat ein Takt von 10ms, ist also 
eigentlich schon zu langsam)

Was es noch gibt sind z.B. PC-Einsteckkarten, die als Master fungieren 
können. Diese sind aber meist teurer als eine Kleinsteuerung.

Vielen Dank an Dich und an den Rest für die teils sehr umfangreichen 
Antworten.

Ich fasse zusammen:

1) Wenn Menschen Entscheidungen über Dinge treffen, von denen sie keine 
Ahnung haben, kommt nur Schrott dabei heraus.

2) Wenn man so ein Projekt lostritt, dann richtig, oder gar nicht. 
Halbheiten bringen nur Ärger.

3) Damit das IO-Link-Device überhaupt laufen kann brauche ich jetzt noch 
einen Profinet-Master in Form einer SPS. Ohne SPS, ohne Profinet.

4) Für so ein Projekt keine SPS eingesetzt zu haben, war eine 
katastrophale Fehlentscheidung (wie ich finde).

Na dann weiß ich jetzt mal, woran ich bin und muss mir jetzt eine 
Lösungsstrategie entwickeln.