Core Memory
TwinCAT (3.1.4026 und 3.1.4024) ermöglicht Echtzeit-Tasks dynamisch Speicher innerhalb des Echtzeitkontextes zu allokieren. Da Echtzeit-Tasks keine Speicherblöcke direkt vom Betriebssystem allokieren können, bietet TwinCAT verschiedene Speicherpools an. Diese Pools sind vorab vom Betriebssystem allokierte Speicherblöcke. Diese Speicherblöcke werden an den physischen Speicher angepinnt, um ein Paging beim Zugriff innerhalb des Echtzeitkontexts zu vermeiden.
Wie bereits im Kapitel Registerkarte Settings beschrieben, gibt es für TwinCAT mehrere Speicher-Pools. Diese sind:
Executable RT Memory | Ausführbarer Echtzeitspeicher, dieser wird vom TwinCAT System benötigt und steht dem Anwender nicht direkt zur Verfügung |
Global RT Memory | Globaler Echtzeitspeicher für Speicherallokationen von TwinCAT-Modulen (SPS und C++) im Echtzeitkontext |
Core Memory <n> | Echtzeitspeicher für Speicherallokationen des <n>-ten Echtzeitkernes |
Global ADS Memory | Datenspeicher für die ADS-Kommunikation. Aus diesem Speicher werden Allokationen für ADS-Nachrichten zwischen den TwinCAT-Komponenten allokiert. |
Tc/OS Memory | Speicher-Pool der Usermode Runtime: die Allokation erfolgt beim Aufstarten einer Usermode Runtime. Von diesem Speicherpool werden die anderen Speicherpools bei Verwendung einer Usermode Runtime bedient. |
Die Größe des Globalen RT Memory ist über die Option Router Memory in der TwinCAT-3-Engineering-Umgebung für jedes Projekt einstellbar. Seit der TwinCAT-Version 3.1.4026 ist der Datenspeicher für ADS-Nachrichten abgetrennt vom „Router Memory“ und als eigenständiger globaler ADS-Memory vorhanden. Die Größe des globalen ADS-Memory wird ermittelt aus der Größe des Globalen RT-Speichers und entspricht 25 % seiner Größe, maximal aber 32 MB.
Mit der TwinCAT Version 3.1.4026 wurde zudem ein weiterer Speicherpool eingeführt, der Core Memory. Der Core Memory bietet für jeden einzelnen Echtzeitkern einen dedizierten Pool für die Echtzeit. Ist der Core Memory für einen Echtzeitkern konfiguriert, wird zuerst versucht, aus diesem Speicherpool den angeforderten Speicher zur Verfügung zu stellen. Ist dieser nicht ausreichend, wird der Speicher aus dem globalen Echtzeitspeicher verwendet.
Der Core Memory erlaubt damit parallele Speicher-Allokationen von verschiedenen Kernen parallel und unabhängig voneinander zu verarbeiten. Für den Zugriff auf den globalen Echtzeitspeicher müssen parallele Speicherallokationen von verschiedenen Kernen sequenziell bearbeitet werden. Das kann bei vielen Speicherallokationen innerhalb eines Echtzeitzyklus zu Wartezeiten führen und ist damit ein Performance-Engpass, z. B. bei Vision-Anwendungen.