Writing Project Changes to the Controller
Note
The availability of the 'Write Changes' function described in this topic is controller-dependent. |
Beside the 'Write and Start' commands, the controller context menu and cockpit may provide two commands 'Write and Start Project Changes' (with and without project sources). The purpose of these commands is to write and apply project modifications to the controller with one mouse click,
without stopping the running controller.
If possible, the entire process is performed in real-time. Depending on the modifications made in the current project and the controller performance/usage, however, real-time violations may occur when the controller switches to the new project because user tasks may not be processed for a short time. Refer to the section "Background: Exact task scheduling vs. real-time violation" for details.
Unintended machine operation
- Make sure that any real-time violations which may occur when executing the 'Write and Start Project Changes' command cannot result in any hazardous situations.
- Verify the effect of possible real-time violations on the timing and performance of your entire application.
- 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.
|
'Write and Start Project Changes' is possible while the controller is in STOP or RUN state. If performed in STOP state, it is started automatically afterwards. If possible, a hot start is executed. Otherwise, a warm or cold start is made. If the controller is in RUN state when executing the 'Write and Start Project Changes' command, the runtime takes the required data/values from the "old" project version in real-time (if possible) and continues program execution. This corresponds to an implicit hot start.
After completing the Write Project Changes operation and when the controller executes the modified program, PLCnext Engineer automatically activates the debug mode, i.e., all currently opened variables tables and code worksheets display variables values read from the target.
Note
The descriptions in this topic also apply to the command 'Write and Start Project Changes (with sources)' which includes the project sources and stores them on the controller. |
Observe that there are some restrictions (listed below), i.e., situations when writing changes to the controller is not possible due to the project modification you made before.
Use cases: writing project changes is possible after...
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.
Restrictions
'Write and Start Project Changes'
is
not possible
- while breakpoints are set on the target. Before writing changes, you have to remove all breakpoints.
- 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.
Writing project changes with forced variables on the target
If variables are forced on the target and you execute a 'Write and Start Project Changes' command, the following applies:
- If the project to be downloaded is equivalent to the project on the target device, the forced variables are still forced after the command.
- If the project to be downloaded is not equivalent to the project on the target device and the online item descriptor (see below) of the forced variables has not been changed, the forced variables are still forced after the command (the firmware of the target device retains the force list).The online item descriptor of a forced variable is considered changed, if:
- A forced variable has been deleted or renamed.
- The data type of a forced variable has been changed and the data types are not compatible or the value of the forced variable is not compatible to the new data type.
- The connection of a forced variable to a process data item (I/O) has been changed or removed.
- The usage of a forced variable has been changed from 'IN port', 'OUT port', 'Instance', or 'Program' to 'Local'.
- If the project to be downloaded is not equivalent to the project on the target device and the online item descriptor (see above) of the forced variables has been changed, a message appears informing you that the forced variables on the target device will be unforced when you continue. Click 'Yes' to continue and unforce all variables on the target or cancel the download with 'No'.
Treatment of data types
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.
How to write project changes
- 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.
Background: Exact task scheduling vs. real-time violation
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: Potentially hazardous modifications
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.
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.
|