QUESTION:   
What mechanisms are there for consistent data transfer in S7-400?

ANSWER:
Consistent data Data that belongs together with respect to content and which describes a process state at a specific point in time is known as consistent data. For data to be consistent it must not be changed or updated during processing or transfer.   

Example 1:  
In order for there to be a consistent image of the process signals available to the CPU for the duration of the cyclic program processing, the process signals are read into the process image of the inputs before program processing and written to the process image of the outputs after program processing. Then during program processing the user program does not access the signal modules directly when addressing the operand areas Inputs (I) and outputs (Q), but accesses the internal memory area of the CPU in which the process image is located.   
Example 2:  
Inconsistency might occur if a communications block (e.g. SFB 14 "GET", SFB 15 "PUT") is interrupted by a process alarm OB of higher priority. Now, if in this process alarm OB the user program changes the data that has already been partially processed by the communications block, then the data transferred is partly from the time before the process alarm processing and partly from the time after process alarm processing. 
This means that this data is inconsistent.     

SFC 81 "UBLKMOV"   
With SFC 81 "UBLKMOV" you copy the contents of one memory area (= source area) consistently into another memory area (= target area). The copying procedure cannot be interrupted by any other activities of the operating system.  
With SFC 81 "UBLKMOV" you can copy the following memory areas:

• Marker
• DB contents
• Process image of the inputs
• Process image of the outputs

The maximum data volume that you can copy is 512 bytes. Please note the CPU-specific restrictions which you can take from the operations list for example.   

Since the copying procedure cannot be interrupted, the alarm response time of your CPU can be increased when implementing SFC 81 "UBLKMOV".   

Source and target areas must not overlap. If the specified target area is greater than the source area, then only as much data is copied into the target area as is in the source area. If the specified target area is less than the source area, then only as much data is copied as can be taken by the source area.    

Consistency in communications blocks and functions  
With the S7-400 communications jobs are not processed in the cycle checkpoint, but in fixed time slices during the program cycle. On the system side the data formats byte, word and double-word can always be processed consistently, i.e. transfer and processing of 1 byte, 1 word (= 2 bytes) or 1 double-word (= 4 bytes) cannot be interrupted.  
If communications blocks (e.g. SFB 12 "BSEND") that can only be used in pairs (e.g. SFB 12 "BSEND" and SFB 13 "BRCV") and which access common data are called in the user program, then the access itself to this data area, e.g. via the "DONE" parameter can be coordinated. The consistency of the data that is transferred locally with these communications blocks can thus be ensured in the user program.  
The behavior is different with S7 communications functions with which no block is required in the user program in the target device (e.g. SFB 14 "GET", SFB 15 "PUT"). Here you have to take into account the size of the consistent data already when programming.   

Access of the main memory of the CPU  
The communications functions of the operating system access the main memory of the CPU in blocks of a fixed size. The block size is CPU-specific and is 32 bytes for the S7-400 CPUs.  
This ensures that the alarm response time is not prolonged when communications functions are implemented. Since this access is asynchronous to the user program, you cannot transfer just any number of bytes of data consistently.
The rules you have to follow to guarantee data consistency will be explained in the following.

Consistency rules for SFB 14 "GET" or reading variables

• Active CPU (data recipient): read out the receive area in the OB by calling SFB 14 or, if this is not possible, reading the receive area after processing of SFB 14 has finished.
• Passive CPU (data sender): write only as much data to the send area as specified by the block size of the passive CPU (data sender).
• Passive CPU (data sender): write the data to be sent to the send area with interrupt lockout.

The following figure gives an example of data transfer for which no data consistency can be guaranteed, because the second consistency rule has been broken: 32 bytes are transferred although the block size of the passive CPU (data transfer) is only 8 bytes.

Fig. 1: Example of data transfer

Consistency rules for SFB 15 "PUT" or writing variables

With SFB 15 "PUT" the data is transferred consistently if you observe the following consistency rules:

• Active CPU (data sender): write to the send area from the OB in which you call SFB 15 or, if not possible, write to the send area after the first call of SFB 15 has been terminated.
• Active CPU (data sender): write only as much data to the send area as specified by the block size of the passive CPU (data recipient).
• Passive CPU (data recipient): read the data received with interrupt lockout from the receive area.

The following figure shows an example of data transfer for which data consistency cannot be guaranteed because the second consistency rule has been broken: 64 bytes are being transferred although the block size of the passive CPU (data recipient) is only 32 bytes.

 Fig. 2: data transfer without guaranteed data consistency

Consistent transfer of large data blocks across several variables can be made in the user program of S7-400 with SFC 81 "UBLKMOV" (uninterruptable block move).

Consistent access can then be made to this data, for example with SFB 14 "GET", SFB 15 "PUT and by reading/writing variables.  

Reading data consistently from a DP standard slave and writing it consistently to a DP standard slave 

Reading data consistently from a DP standard slave with SFC 14 "DPRD_DAT"  
With SFC 14 "DPRD_DAT" (read consistent data of a DP standard slave) you read the data of a DP standard slave consistently. If no errors occur during data transfer, the data read is entered into the target area covered by RECORD.   
The target area must be of the same length as that you have configured with STEP 7 for the selected module. Each time you call SFC 14 you can only access the data of a module/DP ID at the configured start address.  

Writing data consistently to a DP standard slave with SFC 15 "DPWR_DAT"

Notes:  
The PROFIBUS DP standard defines upper limits for the transfer of consistent user data (see next section). Regular DP standard slaves keep to these limits. For older CPUs (<1999) there are CPU-specific restrictions for the transfer of consistent user data.   
Refer to the relevant technical data for these CPUs under the keyword "DP master – user data per DP slave" to find out the maximum length of the data that the CPU can read consistently from a DP standard slave and can consistently write to a DP standard slave. More recent CPUs exceed with this value the length of the data that a DP standard slave makes available or accepts.   

Maximum upper limit for transferring consistent user data to a DP slave
The PROFIBUS DP standard stipulates upper limits for the transfer of consistent user data to a DP slave. This is why in a DP standard slave a maximum of 64 words = 128 bytes of user data can be transferred consistently in a block.   
When configuring you define the size of the consistent area. For this in the special code format (German abbreviation: SKF) you can set a maximum length for consistent data of 64 words = 128 bytes (128 bytes for inputs and 128 bytes for outputs). Anything longer is not possible.  
This upper limit applies only for pure user data. Diagnostics and parameter data are grouped into complete data records and are thus always transferred consistently.   
In the general code format (German abbreviation: AKF) you can set a maximum length for consistent data of 16 words = 32 bytes (32 bytes for inputs and 32 bytes for outputs). Anything longer is not possible.   
In this context, please also note that a CPU 41x as DP slave generally on a non-system master (connection via GSD) has to be configurable via the general code format. For this reason the transfer memory of a CPU 41x as DP slave to the PROFIBUS DP is a maximum of 16 words = 32 byte in size.   

Consistent data access without implementing SFC 14 or SFC 15  
Consistent data access of > 4 bytes is also possible for the CPUs listed below without SFC 14 or SFC 15. The data area of a DP slave that is to be transferred consistently is transferred to a process image partition. The information in this area is then always consistent. You can then access the process image via load/transfer commands (e.g. L EW 1).   
This offers a particularly convenient and powerful option (low runtime load) for accessing consistent data. This then makes it possible to efficiently incorporate and parameterize drives or other DP slave, for example. 

This applies for the following CPUs from firmware version 3.0 onwards:

S7-400 CPU	MLFB
CPU 412-1	6ES7 412-1XF03-0AB0
CPU 412-2	6ES7 412-2XG00-0AB0
CPU 414-2	6ES7 414-2XG03-0AB0
CPU 414-3	6ES7 414-3XJ00-0AB0
CPU 416-2	6ES7 416-2XK02-0AB0
CPU 416-3	6ES7 416-3XL00-0AB0
CPU 417-4	6ES7 417-4XL00-0AB0
CPU 414-4H	6ES7 414-4HJ00-0AB0
CPU 417-4H	6ES7 417-4HL01-0AB0

Table 1: CPUs that support consistent data access without SFC14/SFC15

When you make a direct access (e.g. L PEW or T PAW) there is no I/O access error. 

Important for converting from the SFC14/15 solution to the process image solution:

•   When converting from the SFC14/15 solution to the process image solution it is not recommended to use system functions and the process image at the same time. Basically, the process image is tracked when writing with the system function SFC15, but in the case of reading not. This means that the consistency between process image values and the values of system function SFC14 is not guaranteed. 
• In the SFC 14/15 solution the SFC 50 "RD_LGADR" outputs different address areas to those in the process image solution.
• If you implement a CP 443-5 ext, simultaneous use of system functions and the process image leads to the following errors: there is no read/write from/to the process image and/or it is no longer possible to read/write with the SFC 14/15.

Example:  
The following example (for the process image partition 3 "TPA 3") shows one possible configuration in the HW Config: 

• TPA 3 at output: these 50 bytes are consistent in the process image partition 3 (drop-down list "Consistent over -> Total length") and can thus be read via normal "Load input xy" commands. 
• The drop-down list selection "Process image partition -> ---" under Input means no storing in the process image. Handling is only possible with the system functions SFC14/15. 

Fig. 3: Configuring the DP slave properties in the HW Config