K-bus Cycle

K-bus modes

The K-bus mode (the type of synchronisation between the K-bus cycles and the DP cycle) is set via the UserPrmData:

FreeRun mode

Slow FreeRun (default setting)

In the FreeRun mode there is no synchronisation between the K-bus cycle and the DP cycle. It is a characteristic feature of the Slow FreeRun mode that the K-bus cycle is called from the main task. Acyclic communication or events result in heavy jitter in the K-bus cycle (KS2000, DPV1, terminal diagnosis, etc.), because all of these functions are also called from the main task.

Fast FreeRun

To avoid the jitter resulting from acyclic communication or events and to achieve fast K-bus update times, the Fast FreeRun mode can be activated. The K-bus cycle is called by a higher priority task, controlled by a timer. At the end of the K-bus cycle the low-priority tasks (DPV1, KS2000 interface, etc.) are assigned computing time corresponding to 12.5 % of the preceding K-bus cycle duration, before the next K-bus cycle is started. In fast FreeRun mode therefore the inputs and outputs are up-to-date, but are not synchronized to the DP cycle:

Synchronous mode

As explained in the table above, there are three different synchronous modes.

Standard synchronous mode

In standard synchronous mode the K-bus cycle is always started immediately following reception of the Data_Exchange telegram from the DP master. The outputs are therefore generated as quickly as possible, while the input cycles are always one DP cycle old.

It is important here to ensure that the duration of the K-bus cycle plus approx. 20 % (to allow for the lower priority processes on the coupler) is shorter than the DP cycle time (which, under TwinCAT, means the cycle time of the associated task).

Synchronous mode with optimized input update (one cycle)

In optimized input update, the start of the K-bus cycle can be delayed following reception of the Data_Exchange telegram, so that the inputs are more up-to-date than they are in standard synchronous mode, whereas generation of the outputs is more severely delayed. It is important here to ensure that the duration of the K-bus cycle, plus the delay time, plus approx. 20 % (to allow for the lower priority processes on the coupler) is shorter than the DP cycle time (which, under TwinCAT, means the cycle time of the associated task).

The delay time is set by means of the UserPrmData (in µs, in Motorola format). The extended GSD file of the Bus Coupler is, however, necessary for this:

Synchronous mode with optimized input update (two cycles)

In the third mode of synchronous operation, the advantages of the other two operating modes are combined. Two K-bus cycles are carried out within one DP cycle. The first cycle begins immediately after reception of the Data_Exchange telegram from the master, which means that the outputs are generated as quickly as possible. The second cycle is started after a delay time that begins after completion of the first cycle has elapsed, so that the inputs are as recent as possible. It is important here to ensure that two times the duration of the K-bus cycle, plus the delay time, plus approx. 20 % (to allow for the lower priority processes on the coupler) is shorter than the DP cycle time (which, under TwinCAT, means the cycle time of the associated task).

The delay time is set by means of the UserPrmData (in µs, in Motorola format). The extended GSD file of the Bus Coupler is, however, necessary for this:

Dummy output byte

The Bus Coupler's PROFIBUS DP ASIC can only generate an interrupt after reception of a Data_Exchange telegram if output data has been received. This means that at least one output byte must be transferred via DP in synchronous mode. If only input terminals are plugged in, and no output data is therefore present, a dummy output byte can be configured. It is activated in the UserPrmData, and must be entered as the module in the CfgData. The extended GSD file for the Bus Coupler is, however, necessary for this:

It is also necessary for the dummy output byte to be configured in the CfgData before the complex terminals:

K-bus cycle counter

In order for the master to be able to check reliably whether precisely one (or two) K-bus cycles are always being carried out during one DP cycle, a K-bus cycle counter can be transferred in the input data from the Bus Coupler to the master. This is incremented after each K-bus cycle (0 is omitted, so that 1 follows after 255). The K-bus cycle counter must be activated in the UserPrmData and entered as a module in the CfgData. The extended GSD file for the Bus Coupler is, however, necessary for this:

It is also necessary for the K-bus cycle counter byte to be configured in the CfgData before the complex terminals: