Speicherallokation

Im Allgemeinen wird empfohlen, Speicher mit Hilfe von Member-Variablen der Modulklasse zu reservieren. Dies wird automatisch für im TMC Editor definierte Datenbereiche gemacht.
Es besteht auch die Möglichkeit, Speicherplatz dynamisch zu allokieren und freizugeben.

• Operator new / delete
• TcMemAllocate / TcMemFree

Diese Speicherallokation kann in den Transitionen oder dem OP-State der Statemachine genutzt werden.

Wird dabei die Speicherallokation in einem Nicht-Echtzeitkontext vorgenommen, dann wird der Speicher im non-paged Pool des Betriebssystems (blau im Diagramm) allokiert. Im TwinCAT-Echtzeitkontext wird der Speicher im Routerspeicher (rot im Diagramm) allokiert.

Die Freigabe des Speichers kann ebenfalls in den Transitionen oder dem OP-State erfolgen, wobei empfohlen wird, immer in der „symmetrischen“ Transition den Speicher freizugeben, z. B. allokieren in PS und freigeben in SP.

Bei der Nutzung von statischen Variablen sind einige Besonderheiten zu beachten.

Zusätzlich können einige Hinweise zur Implementierung der Transitionen bereitgestellt werden:

• Transitionen IP, PS and SP, PI werden im Non Real-Time Context (z.B. Windows Kernel Mode) ausgeführt.
• Transitionen SO, OS werden hingegen im TwinCAT RT Task Context ausgeführt (Genauer: TcCOM Server Task).
• Transitionen müssen nach dem Pattern "all-or-nothing" implementiert werden. D.h. alle Schritte die erfolgreich ausgeführt werden müssen rückgängig gemacht werden, wenn ein folgender Schritt fehlschlägt.
• Wenn Speicher im OP Zustand allokiert wird, muss dieser in der OS Transition spätestens freigegeben werden.
• Die Transitionen OS, SP, PI sollten so implementiert werden, dass sie immer erfolgreich sind. Es sollen keine Fehlercodes zurückgegeben werden.
• Transitionen sollten symmetrisch implementiert werden d.h. OS und SO sollten invers sein, dito für PS <-> SP und IP <->PI.
• Transition SO sollte als letzten Schritt das Modul bei der Task anmelden (falls ein ITcCaller vorliegt)
• Transition OS sollte als ersten Schritt das Modul bei der Task abmelden (falls ein ITcCaller vorliegt)
• Semaphoren
• Können im Non Real-Time Context kreiert und gelöscht werden
• Nutzung (Pend / Post) ist nur im Real-Time Context erlaubt
• Mehrere Module können gegenseitig in den Zuständen aufeinander warten. Es wird über die InitSeq (default „PSO“) angegeben, in welchen Zuständen die Modul Instanzen jeweils auf das Weiterschalten des Gesamtsystems (und damit aller anderen Module) warten soll.