Projektierung des PROFINET Device
Bei einem PROFINET-Verbindungsaufbau vergibt der Controller dem Device immer eine IP-Adresse aus seinem eigenen Adressraum (wenn das Gerät noch keine bzw. eine andere hat). In TwinCAT wird per Default für ein Device immer die nächst höhere genommen (von der Controller Adapter-Klasse ausgehend), das Subnet und Gateway sind die Gleichen wie die des Controllers. Vor der eigentlichen IP-Vergabe vom Controller an das Device wird über einen ARP ein evtl. Adresskonflikt getestet bzw. überprüft, ob das Gerät bereits diese IP-Adresse hat. Tritt ein Konflikt auf, z. B. dass die IP-Adresse im Netz bereits vergeben ist, stellt dies der IO-Treiber fest und gibt eine entsprechende Meldung im Logger Fenster aus. Erfolgt keine Antwort auf den ARP, nutzt kein Gerät (auch nicht das projektierte Device) diese IP-Konfiguration, was wiederum zur Folge hat, dass der Controller dem Device über einen DCP_SET die IP-Einstellungen zuweist. Wurde über den ARP festgestellt, dass das gesuchte Gerät bereits die zu projektierende IP Adresse hat, wird das Setzen übersprungen.
In diesem Fenster kann außerdem die "InstanceID" und die "FrameID" geändert werden. Die Defaulteinstellungen sind jedoch für die meisten Anwendungen ausreichend. Die Instance ID fließt mit in die Bildung der Objekt UUID ein. Eine Änderung sollte also nur in Ausnahmefällen durchgeführt werden. Bei einer Änderung der Frame ID ist die genutzte RTClass zu berücksichtigen (z. B. für RTClass1 unicast 0xC000 - 0xFAFF). Befindet sich das Gerät an einem IRT Controller und es wurden automatisch alle Geräte nach RTClass3 geschaltet, wird die Frame ID automatisch verwaltet und es besteht keine Eingabemöglichkeit (wird durch "Fast Config" gekennzeichnet).
In diesem Menü kann außerdem die aktuelle Prozessdatenlänge überprüft werden. D.h. die MaxLängen geben an, welche Prozessdatengröße von dem entsprechenden Gerät unterstützt wird, die ActLängen bezeichnen die aktuelle Prozessdatenlänge (incl. IOPS und IOCS). Werden beim Anfügen weiterer Module / Submodule die Maximallängen überschritten, erscheint die entsprechende Fehlermeldung.
Unter dem Reiter "Features" können verschiedene Einstellungen bzgl. Zykluszeit vorgenommen werden. Die Zykluszeit des Controller muss immer für RTCLass1 einer zweier Potenz, bei 1 ms beginnend, entsprechen (1, 2, 4, 8...). Wurde eine falsche Basiszeit gewählt, wird dies über eine entsprechende Meldung angezeigt. Für RTClass3 kann die 1 ms Basiszeit immer wieder durch zwei geteilt werden (bis min. 31,25 µs). Die Device-Zykluszeit kann über den Exponenten verändert werden. Das Minimum ist dabei immer die Controller CycleTime, es sei denn, in der GSDML ist als minimale Zykuszeit eine größere als die des Controllers definiert. Das Maximum beträgt für RTClass1 512 ms. Der "SendClockFactor" steht hier als Zeitbasis fest auf dem Wert 32 (31,25 µs * 32 = 1 ms). Darauf bezieht sich auch der "ReductionRatioFacto"r, d.h. ein RRFactor von 4 bedeutet eine Zykluszeit von 4 ms. Über die Phase kann wieder innerhalb eines Zyklus der Sendezeitpunkt verschoben werden, d.h. bei RR = 4 kann die Phase 1 - 4 betragen. Dieser Wert ist aber erst bei einer synchronisierten Übertragung von Bedeutung.
Außerdem besteht hier die Möglichkeit den PROFINET Watchdog-Faktor zu verstellen. D.h. jedes Gerät überwacht anhand dieses Faktors den Eingang der zyklischen Daten. Steht der Faktor auf dem Default-Wert (3) bedeutet das, dass bei einer RR von 4 drei Zyklen 12 ms benötigen. Somit reagiert ein Gerät nach 12 ms auf fehlende Telegramme (z. B. mit einem Alarm und / oder Abbau der AR). Die Grenzen und Werte werden bei Verstellen der einzelnen Faktoren immer wieder neue berechnet.