adapnex::drivers::wago::cc100::CC100IODriver

Name

Description

core::Task

Base class for schedulable application components. Tasks are combined via TaskGroup and executed by the scheduler according to the given scheduling parameters. See Application::CreateCyclicTaskGroup() and Application::CreateFreewheelingTaskGroup().

Name

Description

CC100IODriver [constructor]

Default constructor

PostUpdate [virtual]

PreUpdate [virtual]

TearDown [virtual]

Update [virtual]

Name

Description

AI1

Analog Input AI1 (values: 0..10V)

AI2

Analog Input AI2 (values: 0..10V)

AO1

Analog Output AO1 (values: 0..10V)

AO2

Analog Output AO2 (values: 0..10V)

DI1

Digital Input DI1

DI2

Digital Input DI2

DI3

Digital Input DI3

DI4

Digital Input DI4

DI5

Digital Input DI5

DI6

Digital Input DI6

DI7

Digital Input DI7

DI8

Digital Input DI8

DO1

Digital Output DO1

DO2

Digital Output DO2

DO3

Digital Output DO3

DO4

Digital Output DO4

PT1

PT1000 Input PT1 (values: 450..4400Ohm)

PT2

PT1000 Input PT2 (values: 450..4400Ohm)

Name

Description

PostUpdate [virtual]

Provides an opportunity to perform processing after all Update() methods have been invoked each cycle. Drivers generally use this to update any outputs that might have been written to by other tasks.

PreUpdate [virtual]

Provides an opportunity to perform processing before any Update() methods are invoked each cycle. Drivers generally use this step to update any inputs that might be consumed by other tasks.

Setup [virtual]

Called once during the setup phase of the application after the setup() function has returned. Any remaining configuration or memory allocation that could not be handled in the constructor should occur here. The order in which Setup() is called for each Task depends on the order in which the containing task groups are created followed by the order in which the tasks are added to their respective task groups. Drivers generally use this step to initialize any peripherals or devices, based on the previously defined configuration.

TearDown [virtual]

Called once during the shutdown phase of the application, after the final update cycle has completed. Tasks generally use this to drive outputs to a safe state, while drivers use it to flush those final values and release any peripherals or devices. TearDown() methods are called in reverse order relative to Setup(), so that a driver added before the tasks consuming its inputs and outputs tears down after them. See Application::Stop().

Update [virtual]

Performs the main processing step for the task. Called repeatedly after the setup phase. The method has no default implementation and must be overridden by every derived class.