# Erfahrung mit IO-Link



## holgermaik (2 Januar 2020)

Hallo Kollegen
ich beschäftige mich seit heute damit eine S7-315 PN mit bestehender ET200S um einen IO-Link Master (6ES7138-4GA50-0AB0) und einen ifm Abstandssensor(O1D100) zu erweitern. (ich weiß - ist bereits ein Auslaufprodukt, soll aber erstmal zum sammeln von Erfahrung dienen)
Dies wäre unsere erste Maschine mit IO-Link.

Was erhoffe ich mir davon:
- einen stabilen Messwert (ohne analoge Wandlung)
- eine Aussage über den Verschmutzungsgrad
- ein Wechsel bei einem Defekt ohne Parametrierung
- eine einfache Diagnose des Sensors

Wie sind eure Erfahrungen mit IO-Link?
Hat die Vernetzung zu einem Mehrwert geführt?
Ist die Instandhaltung einfacher geworden?
Seit ihr bei der IBN auf unerwartete Probleme gestoßen?

oder kostet alles nur Geld und bringt keinen Nutzen?

Über eure Meinung würde ich mich freuen.

Holger


----------



## Deep Blue (3 Januar 2020)

holgermaik schrieb:


> Was erhoffe ich mir davon:
> - einen stabilen Messwert (ohne analoge Wandlung)
> - eine Aussage über den Verschmutzungsgrad
> - ein Wechsel bei einem Defekt ohne Parametrierung
> - eine einfache Diagnose des Sensors





> Wie sind eure Erfahrungen mit IO-Link?


Ich kann nur Gutes ab dem ersten Einsatz berichten. Bin zwar "nur" Endkunde, aber habe damit RFID von Siemens komplett durch IO-Link mit PN von ifm abgelöst und es läuft seit dem 1. Tag absolut zuverlässig. Weiterhin habe ich Lichtschranke, Initiatoren und auch Schalter im Feld verbaut und per IO-Link angeschlossen. Als Aktoren steuere ich Magnetventile.



> Hat die Vernetzung zu einem Mehrwert geführt?


Ja, im Feld kann ich auf Unterverteilungen z. T. verzichten da ich IP67 Master von ifm einsetze (AL1101, Al1103) . Benötige ich einen Sensor habe, dann habe ich einfach mit M12 die Möglichkeit einen im Feld zu platzieren. 



> Ist die Instandhaltung einfacher geworden?


Ja, musste schon mechanisch zerstörte Antennen austauschen. Einfach auswechseln, fertig. Alles M12, kein/kaum Werkzeug notwendig. Die Möglichkeit eine Lichtschranke auf Verschmutzung zu prüfen habe ich in der Fehlermeldung der SPS mit aufgenommen. Da es immer mehr Sensorik im Feld gibt, ist eine Pro-Aktive Instandhaltung absolut unerlässlich. Es wächst ja leider kein Fach-Nachwuchs auf den Bäumen. Daher muß die Technik intelligenter agieren. Weiterhin ist durch die Parametrierung es nicht möglich 2 unterschiedliche Sensoren oder Aktoren zu vertauschen. Sind quasi mit dem Port verheiratet. 



> Seit ihr bei der IBN auf unerwartete Probleme gestoßen?


Wenn man sich an die Inbetriebnahme im TIA einmal angefreundet hat ist danach alles ein Klacks. Zusätzlich ist LR Device noch eine große Hilfe. 



> oder kostet alles nur Geld und bringt keinen Nutzen?



Wenn ich die Möglichkeiten der Erweiterung im Feld sehe, den Tausch gegen hartverdrahtete Sensorik und die Diagnosemöglichkeiten ist IO-Link ein absoluter Zugewinn. Weiterhin kostet ein IO-Link Sensor genauso viel wie einer ohne diese Technologie. Da hat man quasi keine Wahl als zuzugreifen, auch wenn man es nicht braucht. Ist in unserer Werksspezifikation fester Bestandteil geworden.
Weiterhin ist in Zeiten von Industrie 4.0 jeder Sensor in der Produktion für das Controlling aber auch dem Einkauf oder Logistik eine Hilfe. Man hat sehr schnell einen Produktzähler oder eine Effektivitätsmessung auf die Beine gestellt.


----------



## Blockmove (3 Januar 2020)

Wir setzen IO-Link schon eine ganze Weile ein mit sehr guten Erfahrungen ein.
Allerdings versuchen wir auf Features wie die automatische Parametrierung zu verzichten.
Die meisten Sensoren liefern ihre Prozesswerte (Druck, Abstand, ...) auch ohne Parametrierung.
Problem an dem ganzen ist - unserer Meinung nach - dass sich einfach noch zuviel im Bereich der Master und der Integration in S7 / TIA ändert.
Sobald die Parametrierung sauber über die Hardware-Konfig ohne Zusatztools funktioniert, sieht es besser aus.

Gruß
Blockmove


----------



## Ralle (3 Januar 2020)

Ich sehe das wie blockmove.
Spezialitäten sind mit IO-Link möglich, (Eingang auch als Ausgang nutzbar etc.) aber sobald dort jemand eine Änderung machen muß, der IO-Link kaum kennt oder wenn man nach mehreren Jahren an einer Anlage erweitert bzw. Fehler sucht, hat man schnell ein Problem. Leider kann man (jedenfalls bis vor 2 Jahren, mein Stand) keine zentrale Sicherung der Konfiguration aller IO-Link-Geräte am Bus) über das PN machen. So muß man an jeden Master ran und gut dokumentieren. Wir sind von IO-Link größtenteils wieder weg und nutzen da jetzt auch Siemens, da es einfach besser integriert, also komplett in der Hardware-Konfiguration parametrierbar ist.


----------



## rostiger Nagel (3 Januar 2020)

Ralle schrieb:


> Wir sind von IO-Link größtenteils wieder weg und nutzen da jetzt auch Siemens, da es einfach besser integriert, also komplett in der Hardware-Konfiguration parametrierbar ist.



Hallo Ralf,
den Satz muss du mir mal erklären!
Nutzt ihr IO-Link von Siemens oder etwas anderes von Siemens?


----------



## Blockmove (3 Januar 2020)

@Ralle
Für die meisten Master gibt es spezielle FBs für Backup und Restore.
Aber bisher haben wir darauf verzichtet.


----------



## Deep Blue (3 Januar 2020)

Ralle schrieb:


> Leider kann man (jedenfalls bis vor 2 Jahren, mein Stand) keine zentrale Sicherung der Konfiguration aller IO-Link-Geräte am Bus) über das PN machen. So muß man an jeden Master ran und gut dokumentieren.


Ich kann da nur für mich sprechen, aber bei ifm ist keine Sicherung notwendig. Das einzige, was ich mit meinen Mastern anstelle ist, das ich die IP Adresse ändere. Der Rest geschieht alles im TIA. Und wenn mal ein Master getauscht werden muß ist nur die IP zu verändern. Den Rest macht die SPS, welche vom Rang her über dem Master im Feld steht. Da kannst Du nämlich einstellen was Du willst. Wenn eine SPS angebunden wurde hat die das sagen.
Womit man sich allerdings wirklich einmal auseinander setzten muß sind die IO-Link Schnittstellenbeschreibung der angeschlossenen Sensoren oder Aktoren. Das war es dann aber auch schon.

P.S. Gibt tolle Starterpakete von ifm, da ist alles zum spielen drin. https://www.ifm.com/de/de/category/055/055_090/055_090_010#!/S/BD/DM/1/D/0/F/0/T/24


----------



## Blockmove (3 Januar 2020)

@Deep Blue

Mir ist neu, dass ein IFM-Master die Konfig der Sensoren und Aktoren automatisch in TIA ablegt.
Und wieso muss ich die IP-Adresse ändern? Beim Tausch sollte die automatisch über Profinet gesetzt werden.
Sofern Natürlich die Topologie gepflegt ist

Gruß
Blockmove


----------



## Ralle (3 Januar 2020)

Also wir setzen inzwischen Siemens IM157-1 ein, damit im Feld nicht zu viel Kabel rumschwirren. Ich muß sagen, das gefällt mit ganz gut.

Wenn man mit IO-Link nichts "spezielles" macht, also am Master nicht rumkonfigurieren muß, ist das ganz sicher auch gut. Aber wenn es geht, verzichte ich gerne auf weitere externe Programme, die zur IBN notwendig sind. Es sind auch so schon immer einige am Start (z.B. für Servo, Scanner, Kamera, LASER, Label-Drucker). Wir hatten auch schon Beckhoff-Klemmen im Feld, aber auch hier war die Parametrierung teilweise über das SPS-Programm zu erledigen. Hatte man den Baustein fertig, was das ganz ok, aber wenn ich Hardware nutzen kann, bei der ich das in der Hardwarekonfig erledigen kann, ist mir persönlich das allemal lieber und auch irgendwie zukunftssicherer.


----------



## Deep Blue (3 Januar 2020)

Die Konfig der Sensoren kommt aus der Hardwareprojektierung im TIA.


----------



## rostiger Nagel (3 Januar 2020)

Deep Blue schrieb:


> Die Konfig der Sensoren kommt aus der Hardwareprojektierung im TIA.



Ich bin ja nicht vertraut mit IO-Link, aber das sieht für mich jetzt nur
als reine Adresszuweisung aus. Wenn man jetzt am Sensor etwas 
konfigurieren möchte, benötigt man doch bestimmt eine Software
des Herstellers...oder?


----------



## Blockmove (3 Januar 2020)

Das ist lediglich die Betriebsart und Adressen für den Datenaustausch.


----------



## Deep Blue (3 Januar 2020)

rostiger Nagel schrieb:


> Wenn man jetzt am Sensor etwas
> konfigurieren möchte, benötigt man doch bestimmt eine Software
> des Herstellers...oder?



Nein, benötigt man nicht. Der Adressbereich gibt an wo du Informationen Anhand der Schnittstellenbeschreibung vom Hersteller her bekommst oder aber Anweisungen rein schreibst. Ich lese z. B. die Qualität der Reflexion von Lichtschranke aus, aufgetretenen Fehler der Sensorik oder ein einfaches True oder False bei einem Initiator. Genauso schreibe ich in den Adressbereich ID Nummern meiner Rfid Tags oder versetzen Antennen in den Lese- bzw. Schreibmodus bzw. deaktiviere diese, wenn nötig. Alles passiert anhand der Registeradresse in deinem Code.


----------



## Ralle (3 Januar 2020)

Also wir mußten an dei Master (Balluff) ran, als es galt Eingänge als Ausgänge umzukonfigurieren. Hier ein Haken, dort noch etwas ändern, man mußte schon wissen, was da läuft. Ist ja schon eine Weile her, möglicherweise gibts da Verbesserungen. Per Web-Oberfläche geht das schon, aber so mal eben schnell, war nicht.
Wenn einem dann der Master stirbt, dann kommt die Anlage ohne Eingriff in den neuen Master nicht mehr an den Start, was ich nicht so mag, da man einfach oft vergessen hat, wie das funktionierte und manchmal schlicht nicht weiß, was ein anderer Kollege da so alles eingestellt hat.


----------



## Blockmove (4 Januar 2020)

Deep Blue schrieb:


> Nein, benötigt man nicht. Der Adressbereich gibt an wo du Informationen Anhand der Schnittstellenbeschreibung vom Hersteller her bekommst oder aber Anweisungen rein schreibst. Ich lese z. B. die Qualität der Reflexion von Lichtschranke aus, aufgetretenen Fehler der Sensorik oder ein einfaches True oder False bei einem Initiator. Genauso schreibe ich in den Adressbereich ID Nummern meiner Rfid Tags oder versetzen Antennen in den Lese- bzw. Schreibmodus bzw. deaktiviere diese, wenn nötig. Alles passiert anhand der Registeradresse in deinem Code.



Das ermöglichen andere IOL-Master ebenfalls. Allerdings nicht über die zyklische Kommunikation.
Der Nachteil bei Mastertausch bleibt bestehen.
Du musst Bausteine erstellen / aufrufen um die Master- und / oder Sensorkonfiguration zurück zuschreiben.

Komfortabel (und deutlich praxistauglicher) wäre es, wenn ich in TIA die IODD - Dateien ähnlich wie GSD oder GSDML importieren könnte und in der Hardwarekonfig Master UND IOL-Teilnehmer konfigurieren könnte.
Würde TIA die IODD kennen, dann wäre das Thema mit den Registernummern auch deutlich besser zu lösen. So suchst du dir aus der Kommunikationsbeschreibung die Registernummer und die Datenbreite und kannst dann suchen, wo der Datenbereich in der Steuerung zu finden ist. Zeitgemäß ist anders.

Anfangs empfand ich das Thema Konfiguration über Browser als Fortschritt, da ja keine Software mehr erforderlich ist.
Allerdings hast du mittlerweile auf vielen IT-gemanageten Notebooks solche Restriktionen, dass du die Konfigseiten nicht mehr aufrufen kannst.

Fazit:
Ich will die alten DIP-Schalter aus S5-Zeiten zurück.
Alte Baugruppe raus ... Neue Bausgruppe daneben legen ... Schalter gleich einstellen ... Fertig

Gruß
Blockmove


----------



## Heinileini (4 Januar 2020)

Blockmove schrieb:


> Ich will die alten DIP-Schalter aus S5-Zeiten zurück.


Bei den damals zu bewältigenden AdressRäum[ch]en waren die MäuseKlaviere tatsächlich keine schlechte Lösung.
Aber stell Dir mal "zeitgemässe" (z.B. 64-polige) LäuseKlaviere in SMD-Technik vor, die Du nur noch unter dem Mikroskop bedienen könntest!


----------



## HaDi (4 Januar 2020)

Blockmove schrieb:


> Ich will die alten DIP-Schalter aus S5-Zeiten zurück.
> Alte Baugruppe raus ... Neue Bausgruppe daneben legen ... Schalter gleich einstellen ... Fertig
> 
> Gruß
> Blockmove



Das Gesicht wenn man kapiert dass man die Schalterstellungen in die falsche Richtung übernommen hat: unbezahlbar!

Grüße von HaDi


----------



## Blockmove (4 Januar 2020)

HaDi schrieb:


> Das Gesicht wenn man kapiert dass man die Schalterstellungen in die falsche Richtung übernommen hat: unbezahlbar!
> 
> Grüße von HaDi



Das Schönste was mir mal passiert ist:
An einer Baugruppe hatte Siemens den 8-fach DIP-Schalter um 180° gedreht eingebaut und der Schalter war von einem anderen Hersteller.
Da war dann auch noch On/Off anders rum.
Wir haben x Versuche gebraucht bis es klappte ... Man sollte nicht glauben, dass sich 2 Elektriker so doof anstellen können.
Für die "Jungen" unter uns:
Das war zu einer Zeit als es noch kein Internet und Google gab.


----------



## Chräshe (4 Januar 2020)

Hallo Holger,

  bis jetzt bin ich noch nicht in die Versuchung gekommen, IO-Link einzusetzen.

  Den vermeintlichen Vorteilen, sehe ich folgende Nachteile Gegenüber:
-          Komplexität wird von der Einstellung vor Ort, nur ins SPS-Programm oder Zusatz-Tool verlagert
-          Die Austauschbarkeit zu alternativen Hersteller wird schwieriger
-          Die Wartbarkeit nimmt eher ab, da Software und Hardware nicht über längere Zeiträume unverändert verfügbar bleiben

  Natürlich ist das auch abhängig vom Einsatzort. Bei Serienmaschinen macht es mehr Sinn, einmalig mehr Aufwand in die Software zu stecken und anschießend die Einstellungen auf alle andere Maschinen zu kopieren. Nur bezweifle ich, dass das immer so einfach geht, wie die Werbung verspricht.

  Gruß
Chräshe


----------



## Blockmove (4 Januar 2020)

Chräshe schrieb:


> Hallo Holger,
> 
> bis jetzt bin ich noch nicht in die Versuchung gekommen, IO-Link einzusetzen.
> 
> ...



Ganz so negativ darf man es nicht sehen.
Bei allen IO-Link Master, die ich kenne, kannst du angeben, ob eine Prüfung des IOL-Gerätes ausgeführt werden soll.
Teilweise sogar mehrstufig. Also z.B. gleicher Typ, gleicher Hersteller, oder keine Prüfung.
Solange die Datenlängen von Prozess- und Konfigdaten ziemlich übereinstimmen, ist der Tausch (meist) ohne Software möglich.
Wie bereits geschrieben, arbeiten wir - wo nur möglich - nur mit den reinen Prozesswerten ohne Konfig.
IO-Link macht uns (und den Instandhaltern) hier das Leben sogar einfacher, da du z.B. bei Druckschaltern (z.B. IFM PN7xxx) keine Parameterlisten mehr pflegen musst.

Was mich gerade mehr nervt, sind die unterschiedlichen IOL-Profile.
Es gibt V1.0 und V1.1. ET200S kann nur V1.0 und dummerweise gibt es jetzt immer Geräte, die nur noch V1.1 können.
Auf ET200SP will ich aber nicht wechseln.
Ein weiteres Ärgernis bei IP65 / IP67 Mastern ist die Beschaltung der M12-Buchsen. Hier gibt es Typ A und Typ B.
Typ A ist Pin 2 meist ein DI, kann aber auch umschaltbar DI / DO sein. Pin 5 ist undefiniert.
Typ B sind Pin 2 und Pin 5 eine zusätzliche potentialgetrennte Versorgungsspannung.
Bei den Mastern gibt es div. Kombinations und Einstellungsmöglichkeiten.
Hier muss man also als Konstrukteur / Programmierer schon ziemlich aufpassen. Gerade wenn Potentialtrennung wichtig ist.

Als nächstes steht uns jetzt Safety over IOL ins Haus. Bin mal gespannt.
In der Theorie interessant (Schutztürschalter mit Anforderung, Quittierung und Zuhaltung über Standard M12-Kabel), schau mer mal wie die Ausführung wird.

Mein bzw. auch das Fazit meiner Kollegen:
Es lohnt sich, dass man sich mit IOL genauer beschäftigt.
Wir verbauen - wo möglich - keine analogen Sensoren mehr.
Entweder IOL oder Profinet.

Gruß
Blockmove


----------



## Heinileini (4 Januar 2020)

Blockmove schrieb:


> An einer Baugruppe hatte Siemens den 8-fach DIP-Schalter um 180° gedreht eingebaut und der Schalter war von einem anderen Hersteller.
> Da war dann auch noch On/Off anders rum.


Wenn beim DIP eines anderen Herstellers On/Off anders rum war, hat Siemens den mit Absicht um 180° gedreht bestückt, damit die Elektriker keinen Unterschied merken ...


----------



## Cassandra (4 Januar 2020)

Blockmove schrieb:


> Ganz so negativ darf man es nicht sehen.



Zum Glück hören sich deine Anmerkungen 100% positiv an! *ROFL*


----------



## Blockmove (5 Januar 2020)

Cassandra schrieb:


> Zum Glück hören sich deine Anmerkungen 100% positiv an! *ROFL*



Stimmt 
Mich nerven letztlich einfach nur Kleinigkeiten an der Umsetzung.
Wenn du die IOL-Fachleute im Haus hast, dann erzählen sie fast immer als erstes:

Wir können Cloud
Wir haben 2 Netzwerkanschlüsse (1 für die Steuerung einer für die Cloud)
Die Konfiguration geht mit jedem Standardbrowser
...


Also mal hier die Frage in die Runde:
Wer von euch bindet IOL-Master an die Steuerung UND an die Cloud an?
Nutzt das wirklich jemand produktiv an mehreren Anlage / Maschinen?
Hat eine(r) von euch wirklich ein 2. Netzwerk in der Anlage (nicht nur zum Schaltschrank) nur für die Cloudanbindung?

Wenn die Experten mit der Browserbedienung kommen, dann dürfen sie das immer gerne auf einem Siemens TP1500 zeigen.
Führt meist zu recht ratlosen Gesichtern 
Besonders wenn man dann eine IODD hochladen muß.

Am liebsten sind mir dann noch die Hersteller, die Konfiguration von Geräten per NFC oder Bluetooth bringen.
Wir haben im Konzern IPhone und diese sind IT-managed.
Selbst wenn es eine IOS-App gibt, ist da erstmal nix mit schnell mal installieren 

Man merkt einfach, dass die Produktentwicklung in vielen Firmen zu IT-lastig ist.
Man entwicklet Features, ohne auf die Bedürfnisse der "wirklichen" Kunden einzugehen. :twisted:

So um es nun doch noch positiv klingen zu lassen:
Wir setzen IOL sind einigen Jahren ein und haben keinerlei Probleme im Betrieb damit.

Schönen Sonntag
Gruß
Blockmove


----------



## Chräshe (5 Januar 2020)

Blockmove schrieb:


> So um es nun doch noch positiv klingen zu lassen:
> Wir setzen IOL sind einigen Jahren ein und haben keinerlei Probleme im Betrieb damit.



Hallo Blockmove,

ich setze kein IO-Link ein und hab damit auch kein Problem. 

Mit dem Konzept „So einfach wie möglich und so komplex wie nötig“, bin ich bisher ganz gut gefahren.

Gruß
Chräshe

PS: Doch, im Betrieb sind einige IO-Link-Sensoren im Einsatz.
Allerdings werden nur die Normsignale konventionell verwendet.
Das sehe ich als einen der größten Vorteile von IO-Link…


----------



## holgermaik (5 Januar 2020)

Hallo an alle

ich möchte mich erstmal für die vielen Meinungen bedanken.
Über die Sicherung der Master Config hatte ich bis jetzt so noch gar nicht nachgedacht.

Ich werde es erstmal wie Blockmove halten und den Sensor ohne Config betreiben.

Holger


----------



## AUDSUPERUSER (10 Januar 2020)

Blockmove schrieb:


> Stimmt
> Mich nerven letztlich einfach nur Kleinigkeiten an der Umsetzung.
> Wenn du die IOL-Fachleute im Haus hast, dann erzählen sie fast immer als erstes:
> 
> ...



Wir tun das.
Wir holen über den Y-Weg bei ifm Mastern, die Daten, die wir in der Datenbank haben wollen, und werten sie dort aus.
Großer Vorteil ist: An der SPS vorbei.


----------



## MFreiberger (10 Januar 2020)

Moin AUDSUPERUSER,



AUDSUPERUSER schrieb:


> Großer Vorteil ist: An der SPS vorbei.



Warum ist das ein Vorteil? Frage einfach interessehalber.

VG

MFreiberger


----------



## Blockmove (10 Januar 2020)

AUDSUPERUSER schrieb:


> Wir tun das.
> Wir holen über den Y-Weg bei ifm Mastern, die Daten, die wir in der Datenbank haben wollen, und werten sie dort aus.
> Großer Vorteil ist: An der SPS vorbei.



Das "Y" macht aber nur Sinn, wenn ich in der SPS und in der DB unterschiedliche Werte auslesen will.
Beispiel Distanzmesser:
SPS bekommt den Entfernungswert
DB die Betriebsdauer

Bei der Vernetzung kommt dann bei den meisten "Y"-IOL-Mastern, die ich kenne,  das Problem, dass sie keine 4 Netzwerkports haben, sondern nur 2.
Im Normalbetrieb kann ich beide für Profinet nutzen, Im Y-Betrieb sind die 2 Ports den unterschiedlichen Netzen zugeordnet.
Nutze ich also Y, dann wird die Vernetzung aufwendiger und somit teurer.
Kann sein dass das bei IFM anders ist.

Aber das wird ja in Zukunft bei TSN alles besser ... Wenn's denn noch jemand beherrscht


----------



## AUDSUPERUSER (10 Januar 2020)

Blockmove schrieb:


> Das "Y" macht aber nur Sinn, wenn ich in der SPS und in der DB unterschiedliche Werte auslesen will.
> Beispiel Distanzmesser:
> SPS bekommt den Entfernungswert
> DB die Betriebsdauer
> ...



Die Master haben zwei Ports für Feldbus und einen für Ethernet.
Ja, es ist richtig, mehr Verkabelungsaufwand.
Aber dafür hat man beides sauber getrennt und IT und Automatisierung streiten nicht


----------



## AUDSUPERUSER (10 Januar 2020)

MFreiberger schrieb:


> Moin AUDSUPERUSER,
> 
> 
> 
> ...



Der IT-ler nervt nicht jedes Mal den SPS Programmierer, wenn er einen Wert braucht.
Er kann über JSON auf den Master zugreifen, und sich die Werte holen.
Er könnte auch schreiben, sofern der SPSler das im Master freigibt


----------



## Blockmove (10 Januar 2020)

AUDSUPERUSER schrieb:


> Der IT-ler nervt nicht jedes Mal den SPS Programmierer, wenn er einen Wert braucht.
> Er kann über JSON auf den Master zugreifen, und sich die Werte holen.
> Er könnte auch schreiben, sofern der SPSler das im Master freigibt




Der ITler muss letztlich trotzdem nerven. Ihm fehlt nämlich das Prozess-KnowHow.
Irgend jemand muss dem ITler mitteilen welche Werte er vom welchem Master auslesen muss und wie er sie bewerten muss.
Der Elektrokonstrukteur ist immer mit im Boot.
Und nach der Einführungsphase ist es doch so, dass der SPSler zumeist auch noch Condition-Monitoring-Systeme auch noch betreut. 

Wir nutzen als Protokoll OPC UA auf der Steuerung.
Das bietet dem ITler die selben Vorteile wie JSON.
Das Zeitalter von "Lies mal im DB204 das DW12 aus" sind vorbei.

Gruß
Blockmove


----------



## Heinileini (10 Januar 2020)

Blockmove schrieb:


> Der ITler muss letztlich trotzdem nerven. Ihm fehlt nämlich das Prozess-KnowHow.


Weiss er das denn?



> Irgend jemand muss dem ITler mitteilen welche Werte er vom welchem Master auslesen muss und wie er sie bewerten muss.


Welche Werte er auslesen muss? Na gut. Wie er sie bewerten muss? Keinesfalls.



> Und nach der Einführungsphase ist es doch so, dass der SPSler zumeist auch noch Condition-Monitoring-Systeme auch noch betreut.


Eben drum!


----------



## Blockmove (10 Januar 2020)

Heinileini schrieb:


> Weiss er das denn?
> ...
> Welche Werte er auslesen muss? Na gut. Wie er sie bewerten muss? Keinesfalls.



Naja es gibt ITler und ITler 
Im I4.0 Umfeld gibt es auch viele Quereinsteiger in der IT.
Da passen manchmal die alten Vorurteile nicht mehr.
Mit den Kollegen, die die Technik umsetzen hab ich auch selten Probleme.
Wenn dann ist's der tolle Vertrieb.
Wenn dir ein Senior Consultant mit Bachelor of Arts (also Geisteswissenschaften) erzählt, dass die schwäbischen Anlagenbauer in 5 Jahren weg vom Markt sind weil sie das Potential von cloudbasierten SPSen mit 5G nicht erkennen, dann fahr ich schon mal aus meiner Haut.


----------



## Heinileini (10 Januar 2020)

Na klar, Dieter, es gibt so'ne und es gibt solche.
Aber noch sind SPS- und Hochsprachen-Basierte mit Zusammenwachsen beschäftigt und es werden ständig Neue nachwachsen, um sich auch an den Kollisionen dieser Welten zu beteiligen!


----------



## AUDSUPERUSER (11 Januar 2020)

Blockmove schrieb:


> Der ITler muss letztlich trotzdem nerven. Ihm fehlt nämlich das Prozess-KnowHow.
> Irgend jemand muss dem ITler mitteilen welche Werte er vom welchem Master auslesen muss und wie er sie bewerten muss.
> Der Elektrokonstrukteur ist immer mit im Boot.
> Und nach der Einführungsphase ist es doch so, dass der SPSler zumeist auch noch Condition-Monitoring-Systeme auch noch betreut.
> ...



Sorry, wenn ich Dir wiederspreche, aber unser ITler hat das fast ganz alleine gemacht.
Du hast ja meinen Kontakt.
Wenn Du Dir das mal live anschauen möchtest, einfach melden.


----------



## Blockmove (11 Januar 2020)

AUDSUPERUSER schrieb:


> Sorry, wenn ich Dir wiederspreche, aber unser ITler hat das fast ganz alleine gemacht.
> Du hast ja meinen Kontakt.
> Wenn Du Dir das mal live anschauen möchtest, einfach melden.



Wird zwar langsam offtopic, aber mal die Frage:
Was hat der der ITler fast ganz alleine gemacht?

Bei uns gibt es nur sehr wenige IT-Anwendungen im IoT-Umfeld wo ich einen wirtschaftlichen Vorteil im Y-Link sehe.
Beispiel wäre vielleicht Energie- und Luftverbrauch und evtl. vorbeugende Wartung an Werkzeugen.

Gruß
Blockmove


----------



## AUDSUPERUSER (13 Januar 2020)

Werte eingesammelt und ausgewertet.
So wie Du schreibst, z.B. Energiedatenerfassung.
Klar, die Sensoren hat jemand eingebaut und angeschlossen.
Für die Signalerfassung und Auswertung wurde kein Automatisierer gebraucht.

Wie gesagt, komm und schau es Dir an


----------



## AUDSUPERUSER (13 Januar 2020)

https://youtu.be/0V9jxKl1c6w

Hier hat auch jemand Erfahrung mit IO-Link gemacht.
Dank IO-Link gibt es Bier


----------



## Draco Malfoy (16 Januar 2020)

holgermaik schrieb:


> Was erhoffe ich mir davon:
> - einen stabilen Messwert (ohne analoge Wandlung)
> - eine Aussage über den Verschmutzungsgrad
> - ein Wechsel bei einem Defekt ohne Parametrierung
> - eine einfache Diagnose des Sensors



Es ist alles sehr theoretisch. 

1) Der Messwert ist stabil, erscheint allerdings zeitlich versetzt und und mit ungewisser Refresh-Rate, wenn du ihn azyklisch abholst. 
2) Der Verschmtzungsgrad wird nur kommen, wenn diese Erkennung Richtig konfiguriert ist. 
3) Welchel bei einem Defekt erst ab Version 1.1, oder nur mit einem erheblichen Programmieraufwand realisierbar. 
4) Diagnose - mein Gott, 90% der User sind nicht einmal in der Lage, die von der Fa. Siemens bereitgestellten hardwarebasierten Diagnosemöglichkeiten der Baugruppen vollumfänglich auszunutzen, weil kein Mensch weiß, was Diagnose-, Kommen-/Gehen, Ziehen- / Stecken usw. Alarme sind und wie man deren Informationen richtig verarbeitet.

Jetzt kommt, um die Situation vollends durcheinander zu bringen und einen handelsüblichen 55€/h Baustellen-Programmierer-Inbetriebnehmer endgültig aus der Bahn zu werfen, noch das IO-Link. Die Probleme, die damit verbunden sind, und allesamt einen hohen Programmieraufwand erfordern, sind alle alles andere als trivial.

1) Die azyklischen Zugriffe auf den Master erfordern IO-Link Treiber, die gerätespezifisch sind. Ich kann also keine IO-Link fähigen SCHMALZ Vacuum-Ejektoren mit einem Treiber für IO-Link fähige Laserlichtschranken betreiben.
2) An einem Master können durchaus mehrere IO-Link Geräte angeschlossen sein, aber der Master kann trotzdem nur einen azyklischen Auftrag zur selben Zeit verarbeiten. Es muss also eine funktionsfähige Backplane implementiert sein, die sozusagen das Routung und Management der azyklischen Aufträge je Masterbaugruppe übernimmt.
3) Neben den azyklischen Status- und Read-Aufträgen gibt es noch Niederschreiben von Konfigurationsdaten. Das Lesen-/Schreiben dieser Daten muss auch im Treiber integriert sein.
4) Bei großen Mengen an IO-fähigen Geräten kommt eine standardmäßige CPU an ihre Grenzen, da deren Ressourcen für azyklische Kommunikation ebenfalls nicht unbegrenzt sind. Auch diese Ressourcen müssen dann aktiv gemanagt und von einer entsprechenden Routine dynamisch zugeteilt werden.

Ich habe für einen simplen Anwendungsfall mit IO-Linkt fähigen Saugern einen Treiber- und Schnittstellenbaustein mit ca. 2000 Zeilen in SCL geschrieben. Er belegt einen Auftragszähler, tauscht die Daten mit dem Gerät aus, und inkrementiert anschließend den Counter, um anderen IO-Link fähigen Geräten am selben Master den Datenaustausch zu ermöglichen. Daneben findet noch Diagnose der Masterbaugruppe statt und es werden Statusmeldungen zum Gerät und zum Kommunikationsstatus in diesem Baustein generiert.

Und jetzt stelle man sich einmal einen AWL-Programmierer vor, der das alles umsetzten soll. Ich glaube, ich gehe dann besser gleich Vodka trinken, bevor ich mir dieses Schauspiel antue.


----------



## Ralle (16 Januar 2020)

Draco Malfoy schrieb:


> Es ist alles sehr theoretisch.
> 
> Ich habe für einen simplen Anwendungsfall mit IO-Linkt fähigen Saugern einen Treiber- und Schnittstellenbaustein mit ca. 2000 Zeilen in SCL geschrieben. Er belegt einen Auftragszähler, tauscht die Daten mit dem Gerät aus, und inkrementiert anschließend den Counter, um anderen IO-Link fähigen Geräten am selben Master den Datenaustausch zu ermöglichen. Daneben findet noch Diagnose der Masterbaugruppe statt und es werden Statusmeldungen zum Gerät und zum Kommunikationsstatus in diesem Baustein generiert.
> 
> Und jetzt stelle man sich einmal einen AWL-Programmierer vor, der das alles umsetzten soll. Ich glaube, ich gehe dann besser gleich Vodka trinken, bevor ich mir dieses Schauspiel antue.



Da hat du schon Recht, aber...
Man muß hier auch mal Aufwand und Nutzen betrachten.
Möglicherweise reicht es auch aus den Fehler zu melden (Hier eben, dass der Sauger nicht saugt, also kein Teil hält).
Denn auch wenn du den Fehler ganz genau aus den Meldungen und Zuständen des Masters herausbekommst, wird am Ende entweder der Sauger, das Kabel oder der Master ausgetauscht. Denn auch deine genauen Meldungen müssen vom Nutzer erst einmal interpretiert werden. 

Wir Alle kenne doch die Aussagen alá:

User: Die rote Lampe leuchtet!
Ich: Wie lautet die Fehlermeldung?
User: Weiß ich nicht, hab ich weggedrückt und nicht gelesen!
Ich: Geh nochmal hin.
User: Ooooch ist so viel Text, kann ich mir nicht merken!
Ich: Ok, schreib auf, am Besten die Nummer, den Rest such ich mir selbst!


----------



## Draco Malfoy (16 Januar 2020)

Ralle schrieb:


> Da hat du schon Recht, aber...
> Man muß hier auch mal Aufwand und Nutzen betrachten.
> Möglicherweise reicht es auch aus den Fehler zu melden (Hier eben, dass der Sauger nicht saugt, also kein Teil hält).



Des ist ja gerade nicht der Fall ! IO-Link wurde eingesetzt, um Vacuumwerte auslesen und visualisieren zu können, und um das Gerät vom HMI zu parametrieren. Ansonsten hätte man nur die Meldung Vacuum-Ja oder Vacuum-Nein, und das ist eben zu wenig.

IO-Link setze ich dann ein, wenn ich zusätzliche Informationen benötige. Wenn dafür zyklische Daten ausreichen, ist es halb so schlimm. Aber in jedem Fall muss ich einen Treiber-Baustein mit einem zugehörigen Faceplate in der Visualisierung für jedes Gerät spezifisch erstellen. Alles andere ist einfach nicht sachgemäß, bzw. geht am Sinn und Zweck von IO-Link vorbei. Und der Punkt ist dabei der: Wenn überzeugte, mit S7-Touch neu-lackierte S5 Programmierer, die sich immer noch standhaft weigern, mit Strukturen und Multiinstanzen zu arbeiten, auf solche Themen wie IO-Link mit azyklischem Datenaustausch treffen, dann wird das Ergebnis dieser innigen fidelen Liaison einfach ein schwer zu ertragendes Trauerspiel.

Entweder man macht es richtig, dann ist es eben ziemlich aufwendig, und wenn jemand bis dato nicht mit Bibliotheken und angebundenen Faceplates gearbeitet hat, dann soll einfach gleich und ganz die Hände davon lassen, denn einfacher wirds nicht. Ober man lässt es eben.

Wenn ich mir die Webseiten meiner ehemaligen Auftraggeber so angucke, dann faseln sie alle happy fröhlich von IO-Link und I4.0, so, als wären sie dessen Entwickler oder so. Dabei hat die Abteilung vor Paar Jahren wo ich dort gegangen größtenteils noch mit FCs in AWL geschafft, und das werden die heute höchstwahrscheinlich noch nicht aufgegeben haben. Von einer SFC51 oder wie man die verwendet hat dort vor Paar Jahren auch noch keiner gewusst. Auf der S5 gab es keine SFC51. Wovon reden also diese Leute ? So völlig größenwahnsinnig und realitätsblind kann man doch gar nicht sein ?


----------



## Blockmove (16 Januar 2020)

Draco Malfoy schrieb:


> 1) Die azyklischen Zugriffe auf den Master erfordern IO-Link Treiber, die gerätespezifisch sind. Ich kann also keine IO-Link fähigen SCHMALZ Vacuum-Ejektoren mit einem Treiber für IO-Link fähige Laserlichtschranken betreiben.



Der Begriff Treiber ist mir bei IOLink noch nicht untergekommen. Was meinst du damit?
Die ganzen Konfigdaten und azyklischen Prozessdaten sind gerätespezifisch. Als IOLink aus der Taufe gehoben wurde, wurde uns das anders verkauft.
Damals sollte es "Normprofile" und Geräteklassen geben. Naja daraus wurde nie was.

Die von dir genannten Schmalz Ejektoren sind wirklich ein Paradebeispiel, wie man IOLink Scheiße (Entschuldigung für den Ausdruck) umsetzt.
Funktionell sind die Teile klasse, aber anstelle von Fehlernummern wird ein LED-Status ausgegeben. Wichtige Prozesswerte kannst du nur azyklisch auslesen usw.
Aber die Profinet-Variante ist auch nicht besser.

Gruß
Blockmove


----------



## Draco Malfoy (16 Januar 2020)

Blockmove schrieb:


> Der Begriff Treiber ist mir bei IOLink noch nicht untergekommen. Was meinst du damit?


Treiber ist ein Baustein, den du auf deiner SPS schreibst, um mit einem Gerät zu kommunizieren. Treiber übernimmt dabei die Diagnose, und bindet dein Gerät in die Automatisierungsumgebung ein, indem er Daten nach Außen bereitstellt und Eingaben aus dem Programm an das Gerät weiterleitet. Treiber sind Standardbausteine.


----------



## AUDSUPERUSER (17 Januar 2020)

Blockmove schrieb:


> Der Begriff Treiber ist mir bei IOLink noch nicht untergekommen. Was meinst du damit?
> Die ganzen Konfigdaten und azyklischen Prozessdaten sind gerätespezifisch. Als IOLink aus der Taufe gehoben wurde, wurde uns das anders verkauft.
> Damals sollte es "Normprofile" und Geräteklassen geben. Naja daraus wurde nie was.



Die Schmalz Geräte kenne ich nicht, was ist denn bei denen so schlecht gelöst?

Der erste Schritt zur Standardisierung ist gemacht mit dem SmartSensorProfil V2.
Damit kommen wenigstens die Prozessdaten einheitlich und in der gleichen Einheit.


----------



## holgermaik (27 Januar 2020)

Hallo

 4 Wochen sind vergangen und ich hatte etwas Zeit mich mit dem Thema zu beschäftigen, und möchte euch gern meine Erfahrung mitteilen.

 Der erste Stolperstein war die HW Konfig. Mein Sensor liefert 3 Worte an Daten. Also habe ich mich in der HW Konfig für ein 4 Worte PAE entschieden. S7-PCT gestartet – der Sensor lässt sich nicht einfügen, da die Worte nicht lückenlos sind. Also alles gelöscht und von vorn mit 16 Worte.

 Alles konfiguriert und parametriert und auf den Sensor und Master geladen. Meldung: Parametriertet und gefundener Sensor unterschiedlich. Mein Sensor wird als O1D120 erkannt. Parametrierung geändert und geladen. Funktioniert super.
 Man kann über die Messwerte sogar Ober- und Unterlauf ableiten.
 Sensor abgezogen, CPU Stop – OB82 Anforderung.  Super, kann ich gleich noch etwas Hardware Diagnose machen. - Funktioniert auch.

 Sensor gegen einen anderen getauscht, Parameter werden nicht übertragen.
 Nach dem Handbuch muss Backup/Restore explizit angewählt werden. Diesen Menüpunkt gibt es in meinem PCT nicht. Also UpDate auf Ver. 3.5 SP1. Jetzt ist der Menüpunkt zwar vorhanden, lässt sich aber nicht auswählen. Nach weiterer Recherche festgestellt, das dieses Feature erst ab V 1.1 möglich ist. Lässt sich an meinem Master nicht auswählen. Nach weiteren Stunden Handbuch lesen  steht irgendwo ganz klein das mein Master nur Ver. 1.0 unterstützt. Schade.

 Alles wieder auf den Master und Sensor geladen und beim nächsten abklemmen kein OB82 Aufruf mehr! Genauere Prüfung. Die Reaktion der CPU hängt davon ab mit welcher Version von S7-PCT der Master geladen wurde! Sehr unschönes Verhalten! Die Diagnose kann sich also nur auf den Qualifier stützen.


 Mein Fazit:
 Das System hat sicherlich Potential für die Zukunft wenn erst einmal die vielen kleinen Stolpersteine beseitigt sind. Mich hat es im ersten Anlauf nicht überzeugt.


 Holger


----------



## AUDSUPERUSER (27 Januar 2020)

Da hast Du Dir aber auch den aktuellsten Master rausgelassen.
Für den wurde 2013 das letzte Firmwareupdate gemacht.
Da brauchst du Dich nicht wundern, dass noch nicht alles zur Verfügung steht.
Wenn schon Siemens Master dann nimm doch den für die ET200SP.
Der ist V1.1 
Aber wie andere Mütter auch schöne Töchter haben, haben andere Hersteller auch gute Master, es muss nicht mit Gewalt Siemens sein


----------



## holgermaik (27 Januar 2020)

Vom Prinzip stimme ich dir da zu 100% zu. Wie ich bereits in #1 geschrieben habe ist mit durchaus Bewust, dass es sich um ein altes System handelt und ich dadurch mit Einschränkungen rechnen muss.
Da wir aber Endkunden sind, beschäftigen wir uns hauptsächlich mit Instandhaltung, Änderung und Erweiterung.
Wenn ich zu meinem Chef gehe und ihm sage, ich möchte mich mit IO-Link beschäftigen das bringt uns xx Vorteile, der Master Kostet ca. 200Euro, dann sagt er "mach mal". 
Wenn ich aber sage die ET200S ersetze ich gleich mit, für die Visu brauche ich eine neue RT Lizenz und die CPU könnte auch durch eine aktuelle ersetzt werden, dann sagt er "stell mal in die Planung, Siemens liefert ja noch 10 Jahre Ersatzteile, beschäftigen wir uns 2028 mit".

Ich muss also nehmen was ich kriege



> Aber wie andere Mütter auch schöne Töchter haben, haben andere  Hersteller auch gute Master, es muss nicht mit Gewalt Siemens sein


Auch da *ACK*
Habe mir den Wago Master für e!cockpit kommen lassen. Bin ich aber noch nicht zu gekommen mich intensiv damit zu beschäftigen
Holger


----------



## Blockmove (27 Januar 2020)

AUDSUPERUSER schrieb:


> Wenn schon Siemens Master dann nimm doch den für die ET200SP.
> Der ist V1.1
> Aber wie andere Mütter auch schöne Töchter haben, haben andere Hersteller auch gute Master, es muss nicht mit Gewalt Siemens sein



Bei der ET200SP musst du deine Sensoren / Aktoren anklemmen.
Wir nehmen lieber IP67-Master.
Von Siemens wär das dann die ET200eco.
Aber da gilt noch viel mehr, dass andere Mütter schöne Töchter haben.
Bei anderen Müttern gibt es dann z.B. Konfig und Diagnose über Browser, also ohne PCT oder sonstige Software.
Oder auch Safety über IOLINK
Allerdings musst du dann bei  Class A- oder Class B-Anschlüssen aufpassen.

Gruß
Blockmove


----------



## Draco Malfoy (29 Januar 2020)

holgermaik schrieb:


> Hallo
> 
> Man kann über die Messwerte sogar Ober- und Unterlauf ableiten.
> Sensor abgezogen, CPU Stop – OB82 Anforderung.  Super, kann ich gleich noch etwas Hardware Diagnose machen. - Funktioniert auch.
> ...



Kannst Du bitte mehr dazu schreiben ?? Brauche diese Info dringend für meine Diagnose-Bausteine

- Welche Informationen kommen da konkret (zahlenwert der Message, Alarmtyp, Alarm-Specifier ?)
- Was für eine Diagnoseanforderung kommt da ? Kanalbezogen, Maintenance, Qualified ??
- Wo stelle ich das Reaktionsverhalten ein ??

Danke !!!


----------



## holgermaik (2 Februar 2020)

Normale Messung:
Datenwort 1 / Messwert - aktueller Messwert
Datenwort 2 / Reflexion - aktuelle Reflexion
Status Bit 5 / Meldung - False
Qualifier - True

Überlauf (kein Messobjekt):
Datenwort 1 / Messwert - &H 8008
Datenwort 2 / Reflexion - &H 7FFC
Status Bit 5 / Meldung - True
Qualifier - True

Unterlauflauf (Messobjekt zu nah):
Datenwort 1 / Messwert - &H 7FFC
Datenwort 2 / Reflexion -  &H 8008
Status Bit 5 / Meldung - True
Qualifier - True

Drahtbruch:
Datenwort 1 / Messwert - &H 0000
Datenwort 2 / Reflexion -  &H 0000
Status Bit 5 / Meldung - False
Qualifier - False

Zum Einstellen der Reaktion der CPU (OB82 Aufruf) habe ich nichts gefunden. wird durch die Version von S7-PCT vorgegeben.


----------



## Blockmove (2 Februar 2020)

holgermaik schrieb:


> Normale Messung:
> Datenwort 1 / Messwert - aktueller Messwert
> Datenwort 2 / Reflexion - aktuelle Reflexion
> Status Bit 5 / Meldung - False
> ...



Das ist doch der ganz normale Prozessdatenbereich eines optischen Sensors.
Je nach Hersteller und Modell bekommst du diese Daten im zyklischen oder im azyklischen Datenbereich.
Das hat aber - meines Erachtens - nichts mit Diagnose zu tun.


----------



## holgermaik (2 Februar 2020)

Mehr Infos rückt der Sensor nunmal nicht raus.
Frage: Welche Informationen vom Sensor hättet du denn erwartet?


----------



## AUDSUPERUSER (3 Februar 2020)

holgermaik schrieb:


> Mehr Infos rückt der Sensor nunmal nicht raus.
> Frage: Welche Informationen vom Sensor hättet du denn erwartet?



Welche Events werfen denn Deine Sensoren?


----------



## Draco Malfoy (3 Februar 2020)

Mich interessiert speziell, was passiert bei einem OB82 Call => welche Ereignisse werden dort gemeldet und in welcher Form ? 
Kommen da Maintenance Alarme, oder normale Kanaldiagnose, Extended / Qualified ?


----------



## mbi (30 September 2021)

Hallo 
Sorry wenn ich das alte Thema wieder ausgrabe.
Was mich noch interessieren würde ist wenn wir z.B. alles mit Siemens Master ET200SP arbeiten ist dann bei jedem neuen Sensor oder Aktor eine Hardware Config Änderung nötig?
Also SPS wieder auf Stopp setzen?

Kann man da auch z.B. schon Reserve Temperaturfühler vorbereiten welche aber noch nicht angeschlossen sind. 
Ähnlich eine 4 AI  Karte wo man aktuell nur 1 Kanal braucht aber vielleicht später ein Temperatur oder Drucksensor noch angeschlossen wird.
Da kann man ja eigentlich alles machen bis auf die Visualierungsänderung ohne das der Bediener etwas davon merkt oder die Produktivität darunter leidet.

Hoffe meine Frage ist verständlich.


----------



## Wincctia (30 September 2021)

Hallo mb, 

dies läuft über das PCT ( Port Configrations Tool) damit Konfigurierst du dein Modul, ein Cpu Stopp ist für den Download nicht erforderlich. Kurzes Aussetzen der Prozesswerte sind aber vorhanden. Einen Teilnehmer als Reserve würde ich nicht verwende, sonst hast du immer einen < Toten> Teilnehmer, außerdem ist bei Io Link Teilnehmer nicht Teilnehmer. Du müsstest im Vorhinein schon recht genau wissen was du an welchem Port haben willst. Alternativ wäre es noch möglich vom AnwenderProgramm aus per konfigurationssteuerung ändern So könntest du per Visu den passenden Sensor anwählen.

Gruß Tia


----------



## maxder2te (2 Oktober 2021)

mbi schrieb:


> Hallo
> Sorry wenn ich das alte Thema wieder ausgrabe.
> Was mich noch interessieren würde ist wenn wir z.B. alles mit Siemens Master ET200SP arbeiten ist dann bei jedem neuen Sensor oder Aktor eine Hardware Config Änderung nötig?
> Also SPS wieder auf Stopp setzen?
> ...


Ich betreibe meine Siemens IO-Link Master immer im Modus ohne PCT und reserviere ausreichend Ea-Daten pro Kanal (Modus 144/128 oder 68/64) und aktiviertem PQI. 
Da kann man dann im laufenden Betrieb tun und lassen was man will.


----------

