Memory allocation

Generally we recommend reserving memory with the aid of member variables of the module class. This is done automatically for data areas defined in the TMC editor.
It is also possible to allocate and release memory dynamically.

• Operator new / delete
• TcMemAllocate / TcMemFree

This memory allocation can be used in the transitions or in the OP state of the state machine.

If the memory allocation is made in a non-real-time context, the memory is allocated in the non-paged pool of the operating system (blue in the diagram). In the TwinCAT real-time context, the memory is allocated in the router memory (red in the diagram).

The memory can also be released in the transitions or the OP state; we recommend to always release the memory in the "symmetric" transition, e.g. allocation in PS, release in SP.

When using static variables, some special features have to be considered.

In addition, some notes on the implementation of transitions can be provided:

• Transitions IP, PS and SP, PI are executed in a non-real-time context (e.g. Windows Kernel Mode).
• Transitions SO, OS, however, are executed in the TwinCAT RT Task Context (more precisely: TcCOM Server Task).
• Transitions must be implemented according to the "all-or-nothing" pattern. This means that all steps that are carried out successfully must be undone if a subsequent step fails.
• If memory is allocated in the OP state, it must be released in the OS transition at the latest.
• The OS, SP, PI transitions should be implemented in such a way that they are always successful. No error codes should be returned.
• Transitions should be implemented symmetrically, i.e. OS and SO should be inverse, ditto for PS <-> SP and IP <->PI.
• Transition SO should log in the module to the task as the last step (if an ITcCaller is present)
• Transition OS should log off the module from the task as a first step (if an ITcCaller is present)
• Semaphores
• Can be created and deleted in a non-real-time context
• Use (pend / post) is only permitted in a real-time context
• Several modules can wait for each other in the states. The InitSeq (default "PSO") is used to specify the states in which the module instances should wait for the overall system (and thus all other modules) to be switched on.