Using a PROFINET I/O Connection

This topic describes the how to control the RMC via the PROFINET I/O connection's cyclic data. For detail using the acyclic data, see Using PROFINET Record Data. For details on setting up a connection, see the Setting up a PROFINET I/O Connection topic.

Understanding the Sync Register

The cyclic I/O data can operate in two modes: with a Sync Register and without a Sync Register. When using a Sync Register, the first Input Data register and first Output Data register are each reserved as a Sync Register, and the RMC processes incoming data only when the Sync Register changes. When not using a Sync Register, the RMC processes incoming data each time any register in the block changes.

The Sync Registers show up in the Input and Output Data images in the PLC. In the RMC, they are only visible in the Event Log. See Troubleshooting PROFINET for details.

Why Use a Sync Register?

The Sync Register gives the user tight control over synchronization between the PLC and RMC. In applications that do not require this level of synchronization, the user can choose to not include the Sync Register.

The synchronization provided by the Sync Register is useful when:

Setting the Sync Register Mode

To select whether the Sync Register is used:

  1. In the Project pane, expand the Modules folder, double-click the CPU module, and choose PROFINET.

  2. Under Sync Register, select either Use a Sync Register or Do not use a Sync Register.

Using Input Data in the PLC

If the Sync Register is used, then the first register is reserved as the Sync Register. All other registers in the Input Data are controlled by the Outgoing Cyclic I/O Data address specified in the PROFINET Settings Page. When the I/O connection is established, the Input Data is automatically updated in the PLC at the specified PROFINET update time. The PLC can simply use the data whenever it needs it. The RMC does not wait for the Sync Register to change to update its Outgoing Cyclic I/O Data.

Notice that the data types of the variables in the RMC must match the data types of the structure receiving the Input Data from the RMC. Specifically, registers of type REAL in the RMC must correspond to REAL data types in the PLC, and all other RMC data types (DINT and DWORD) should correspond to tags of type DINT or DWORD in the PLC.

Writing Output Data with a Sync Register from the PLC

To write data in the RMC controller using I/O data when the Sync Register is used, do the following in the PLC:

  1. Wait for the Sync Registers in the Input Data and Output Data to match.

  2. Update any Output Data register values, except the Sync Register.

  3. Change the value of the Output Data Sync Register.

  4. Do not change any Output Data registers until the Input and Output Sync Registers match again.

The RMC will apply the Output Data register contents only once.

Writing Output Data without a Sync Register from the PLC

To write data in the RMC controller using I/O data without the Sync Register, simply change the Output Data registers in the PLC and they will get applied in the RMC. Often care must be taken as to the order that the registers are updated to ensure that actions triggered by changes to registers in the RMC have updated values for any parameters they use. It is often necessary to also understand whether the I/O data is updated synchronously to the PLC scan or not.

Writing to the Command Area from the PLC

The Incoming Cyclic I/O Data area can be set up to point to the Command Area registers directly, or indirectly through the Indirect Data Map. The Sync Register should always be used if the PLC will be writing commands to the Command Area. The following sequence is recommended:

  1. Wait Until the Sync In and Sync Out Registers Match
    If they do not match, then this means that another command or set of commands is in progress.

  2. Clear Old Commands from the Command Registers
    Clear old commands from the command registers for each axis. Otherwise, when the Sync Out register is changed, the commands would be re-issued. One method of clearing the old commands is to fill the Output Data array with zeroes.

  3. Write to the Command Registers
    Write the Command registers and all required command parameters to the Output Data for all commands you want to issue. You can issue up to one command per axis. Leave the Command register set to 0 for each axis that will not receive a command.

  4. Change the Sync Out Register
    The easiest way to do this is to add one to it. However, you must take care to handle overflowing this register (the Sync register is a REAL). One method is to add one and then MOD it with some large number, such as 10000. This will make the register count from 0 to 9,999, and then wrap back down to 0 without an error. Take care to ensure that you only update the Sync Out register once so that the commands do not get re-issued.

  5. Wait Until the Sync In and Sync Out Registers Match
    It is important to wait until this occurs before using the status bits in the Input Data (if the Input Data includes any status bits). See the example above for how problems can occur if this step is ignored.

Triggering Commands through the Variable Table

If you have set the Output Data to write to Variable Table registers directly or via the Indirect Data Map, you can use them together with the Program Triggers to start User Programs that issue commands. For advanced applications that require issuing commands and writing to variables, this can be a very efficient method of communication.

To issue a command with this method, you will first need to do the following:

  1. Create a user program that contains the commands you need.

  2. Define a variable in the Variable Table that will be used to start the program. Name it StartProgram, for example.

  3. Create a Program Triggers condition that looks at the value of StartProgram. When the StartProgram variable becomes a certain value, it will start the specified user program. This StartProgram variable can be used to start different programs based on its value.

  4. The user programs should always reset the StartProgram variable to some starting value (such as 0). This is so the Program Triggers will always see the number change when the PLC writes to it. If the number already was 6, and the PLC writes 6, the value doesn't change, and the Program Triggers do not know to start a user program. Typically, the first step in a program should reset the value of the variable.

 

Once the Program Triggers and User Programs have been made, make sure the RMC is in RUN Mode, and use one of the procedures below to start a User Program:

With a Sync Register:

  1. Wait until the Sync In and Sync Out Registers match.

  2. Write a number to the StartProgram variable. The number will specify which user program to run.

  3. If you need to write to other variables (e.g. for defining speeds, setpoints, etc.), do so.

  4. Change the Sync Out Register.
    The easiest way to do this is to add one to it. However, you must take care to handle overflowing this register (the Sync register is a REAL). One method is to add one and then MOD it with some large number, such as 10,000. This will make the register count from 0 to 9,999, and then wrap back down to 0 without an error. Take care to ensure that you only update the Sync Out Register once so that the commands do not get re-issued.

  5. Wait until the Sync In and Sync Out Registers match.
    When the Sync In Register has changed, you know the data has been applied to the RMC. It is important to wait until this occurs before using the status bits in the Input Data (if the Input Data includes any status bits). See the example above for how problems can occur if this step is ignored.
    After the Sync registers match, you can look at the Task Status and Current Program registers to determine if the task is running the program, and when it stops. These registers should be included in the Input Data.

Without a Sync Register

  1. If you need to write to other variables that are used by the user program (e.g. for defining speeds, setpoints, etc.), do so first.

  2. Write a number to the StartProgram variable. The number will specify which user program to run.

Handling Broken Connections

Many applications require some type of action if the PROFINET I/O connection breaks during machine operation. For information on how to handle a broken connection in either the RMC or PLC, see the Handling Broken PROFINET Connections topic.

Troubleshooting

See the Troubleshooting PROFINET topic.

How the I/O Data is Applied to the RMC

When the Sync register is used, and the RMC sees that the incoming Sync Register changes, the RMC applies all the data from the PLC to the specified Incoming Cyclic I/O Data area. When the Sync Register is not used, then when any register changes its value, then all data is written to the specified Incoming Cyclic I/O Data area.

In certain cases, it may take more than one loop time to apply the data. Therefore, not all the data may be valid at the same time. For example, if you are using any of the data to trigger a user program that also uses some of the data, it is important that the user program is not triggered before all the data is valid, otherwise, the user program may use old data.

Data Consistency

When all the incoming data is applied in the same RMC loop time, the data is called consistent. If the data is consistent, you can use all the data immediately. If the data is not consistent, you need to make sure that you do not use the data until it has all been updated.

The following rules apply to data consistency based on where the consuming address is in the RMC:

Variable Table - Current Values

Command Area

Writing the data to the Command Area may take up to 3 ms. After the write is complete, the entire command block is submitted as a single consistent block. Therefore the data is treated as a single consistent block, although it may take several loop times before the block is submitted.

Indirect Data Map

The only data guaranteed to be consistent are variables, if they are placed first in the Incoming Data area of the Indirect Data Map. The size of guaranteed consistent data depends on the loop time:

As soon as the first register is encountered that is not a current or initial variable register, the guarantee for data consistency no longer applies. Remaining registers in the I/O block will be processed as time allows on subsequent motion loops, taking up to a maximum of 10 ms. For this reason, variables should be included first in the Incoming I/O Data Area of the Indirect Data Map in order to ensure their consistency.

Notice that if commands are mapped to the Indirect Data Map, the commands will all be submitted at the same time, after all values have been written.

Other Locations

No data consistency is guaranteed when consuming in other areas (such as axis parameters). The entire write can take as long as 10 ms, with the write being deferred to the next control loop at any point as required to meet loop time requirements.

 

See Also

PROFINET Overview | Setting up a PROFINET I/O Connection | Handling Broken PROFINET Connections | Troubleshooting PROFINET


Send comments on this topic.

Copyright © 2025 Delta Computer Systems, Inc. dba Delta Motion