Writing Project Changes to the Controller

Writing project changes is possible after the following project modifications:

Changing code of existing POU(s).
Inserting/deleting local and global variables.
Changing local and global variables (incl. initial value).
Changing the data type may result in the re-initialization of the particular variable. Refer to section "Treatment of data types" below for further information.
Declaring new FB (user/firmware) instances.
Adding/deleting data types. Refer to section "Treatment of data types" below for further information.
Changing data types declarations. Variables of the modified data type may be initialized. If the value of an affected variable can be converted to the new data type without any losses, the conversion of the value is possible. Refer to section "Treatment of data types" below for further information.
Changing comments in code.
Using a new POU type.
Adding/deleting program instances.
Changing the assignments (mapping) of IN and OUT ports. Note the following when deleting an assignment between an IN and OUT port before writing the project changes to the controller: the IN port keeps the last value of the OUT port that was written before execution of the write command.

'Write and Start Project Changes' is not possible

while breakpoints are set on the target. Before writing changes, you have to remove all breakpoints.

Note
In case of forced variables, writing changes is possible. Variables which have been forced before writing project changes are automatically unforced (the force list is reset and a corresponding desktop alert is issued).

if the button 'Debug/Optimized Code' has been activated or deactivated since the last compile.
if modules/devices have been added, deleted, or edited in the PLANT.
after tasks have been added/deleted or any task properties have been modified.

For most conversions, the conversion does not influence the variable value. After changing the data type of an existing variable, the value of this variable will be kept, if this is possible without any loss. For this, the value range of the data type is decisive. If the variable's value has to be changed due to the different value ranges of the old and the new data type, the variable will not only be converted but instead it will be deleted and then added and initialized.

The following table shows the migration of basic data types. Read the table as follows: a data type is converted from the first (most left) column to the corresponding type on the right.

Conversion possible without any loss (old value = new value)

Conversion results in a newly added and initialized target value

Note

Bitstream data types are always treated as unsigned data types when converting them. This means, for example, a BYTE is based on the same .Net data type as an USINT. As a result, the variables values are always transferred.

For an unsigned > signed conversion, the following applies: the sign is not considered. Example: Conversion BYTE to INT: BYTE#16#FF (BYTE#255) results in the Integer value 255 (INT#16#00FF or INT#255).

Treatment of user-defined data types (arrays, structures, strings)

If a different data type has been selected (resulting in a different data type name), the initial value of the new data type is used.
If the data type has been modified (i.e., the name is unchanged) and the data type definition has been edited, the members of elementary data types are treated according to the rules described above.
When changing the length of a user-defined data type, as many values are taken over from the old variable as the new variable can accept. (Here, the offset at the beginning is decisive not the index.) Excess values, which do not fit into the new variable, are discarded.
If, for example, an array (unchanged data types) is shortened, the remaining elements will keep their value. After enlarging an array (unchanged data types), the elements that have already been contained in the previous array will keep their values, new elements will be initialized. The same applies to structures: kept elements keep their value, new elements are initialized.

Modify the project.
Perform the procedure described in the topic "Commissioning the Application: From Compiling to Debugging", but select one of the following commands instead of 'Write and Start':

Note
If the commands are not available, refer to the description in section "Restrictions". Possibly, you made project modifications that prevent the use of 'Write and start project changes'.
- 'Write and start project changes'
- 'Write and start project changes (with sources)' additionally includes project sources and stores them on the target:
The changes are only written to the target if the compiler detects no errors. Otherwise, the operation is aborted and the controller continues the execution of the current program.
If no errors are detected, the changes (and the project sources, if appropriate) are written to the target and the controller switches from the "old" project to the modified project.
If real-time conditions are violated or if the operation cannot be completed at all, a corresponding message is shown and an entry is made in the online log explaining the reason for the failed operation.

Depending on the changes made in the current project and the controller performance/usage, the entire process is performed in real-time, i.e., without violating real-time conditions of the tasks already running on the controller. Ensuring real-time is only possible if the controller is able to copy all changed data, i.e., the data of all changed POU instances between two controller (user tasks) cycles. In this case, the task scheduling on the controller is kept, no task is invoked with delay, and thus, the controlled automation system is ensured to run within intended limits.

Depending on the changes you have made in the project, i.e., on the number of modified POU instances and the free time slice between two task cycles, the available time interval may be too short to copy all changed POU instances and to switch the controller to the new project version without interruption by the next user task invocation. Ensuring real-time, however, means that the execution of user tasks must no be delayed. For that reason, the exact task execution (on time) takes precedence over the Write Changes process.

Note
If real-time conditions are violated, a corresponding message is shown in PLCnext Engineer and an entry is made in the online log.

Modifications in SFC POUs are allowed in principle but they are considered to be potentially hazardous because they may result in critical controller states when changes are written to the controller while it runs. For example, the sequence of an SFC step chain might be blocked if a step is deleted which is currently active. The deletion of actions is also considered and reported as critical.

In these cases, you will receive a message and have to verify the risk before confirming the warning message in order to continue the process.

WARNING

Unintended machine operation

Verify the impact of modifications in SFC POUs particularly with regard to possibly blocked SFC step chains, for example due to deleted steps or actions.

Do not enter the zone of operation while the machine is operating.

Ensure that no other persons can access the zone of operation while the machine is operating.

Observe the regulations given by relevant sector standards while the machine is running in any other operating mode than "operational".

Use appropriate safety interlocks where personnel and/or equipment hazards exist.

	Conversion possible without any loss (old value = new value)
	Conversion results in a newly added and initialized target value