Hello.

The system has an S7-1200 connected to a PN/PN coupler. The coupler is configured to the specifications from another company. The use of SETIO and GETIO is suggested.

FIGURE 1. Update of IO linked to the coupler.

Please confirm which of the two options is true:

(1) The process image does not need to be updated automatically when using the SETIO and GETIO instructions. These instructions takes over the job of writing / reading the data located on the coupler -- right?

(2) Or should the IO configured for the coupler still have some update rate set (linked to an OB)? Note the automatic update is set in the above picture.

Thanks in advance.

Hi qwazee,

GETIO and SETIO use DPRD_DAT and DPWR_DAT internally. So you do not need to have a process image assigned to the device. But if you do have one assigned, I assume that the process image is updated as it is when using DPRD_DAT or DPWR_DAT.

Kind regards
Stefan

Stefan Arcularius

Hi qwazee,

GETIO and SETIO use DPRD_DAT and DPWR_DAT internally. So you do not need to have a process image assigned to the device. But if you do have one assigned, I assume that the process image is updated as it is when using DPRD_DAT or DPWR_DAT.

Kind regards
Stefan

Thank you Stefan for responding.

In the case of using a PN/PN Coupler, one must configure the IO addresses. More: The configuration of left side and right side should match with type and size for each module slot. Or am I missing something? 

On the S7-1200 system the peripheral area available for automatic updating is (1) inputs: 1024 bytes and (2) outputs: 1024 bytes. I would assume it is possible for my coupler case to configure outside that address range, like we did on the S7-300.

So for example address blocks P#I2000.0 BYTE 192 and P#Q2000.0 BYTE 192. Would that be legal? But surely there is a input-address and output address that cannot be handled. Would for example P#I10000.0 BYTE 192 still work?

Update: Addresses must be within the 1024byte range.

Hi qwazee,

qwazee

In the case of using a PN/PN Coupler, one must configure the IO addresses. More: The configuration of left side and right side should match with type and size for each module slot. Or am I missing something?

The PN/PN coupler does not receive address information, so you do not need to configure one if you are working without a process image. When configuring, it is important to configure the opposite module for each slot between the two sides. For example, if the left side is configured for 128 bytes of input in slot 1, the right side must be configured for 128 bytes of output.

Kind regards
Stefan

Edit: Addresses are also needed when working without a process image. See post below.

Stefan Arcularius

Hi qwazee,

qwazee

In the case of using a PN/PN Coupler, one must configure the IO addresses. More: The configuration of left side and right side should match with type and size for each module slot. Or am I missing something?

The PN/PN coupler does not receive address information, so you do not need to configure one if you are working without a process image. When configuring, it is important to configure the opposite module for each slot between the two sides. For example, if the left side is configured for 128 bytes of input in slot 1, the right side must be configured for 128 bytes of output.

Kind regards
Stefan

Stefan, there must be something trivial / fundamental I am missing. Please explain how is it possible to configure the coupler without specifying the address ranges. See the picture as reference.

Hi qwazee,

Sorry, it was my fault. I thought that by configuring the process image to "None", no IO addresses would be needed. But as I have now verified, this is not the case.

How many bytes of additional IO addresses would you need and how many spares do you have? Perhaps using the Publisher or Storage module type would be an option. This will allow acyclic transfer of up to 4096 bytes using only a view byte of address space. However, this increases the programming effort on both sides.

Kind regards
Stefan

Stefan Arcularius

Hi qwazee,

Sorry, it was my fault. I thought that by configuring the process image to "None", no IO addresses would be needed. But as I have now verified, this is not the case.

How many bytes of additional IO addresses would you need and how many spares do you have? Perhaps using the Publisher or Storage module type would be an option. This will allow acyclic transfer of up to 4096 bytes using only a view byte of address space. However, this increases the programming effort on both sides.

Kind regards
Stefan

Hello Stefan.

For this project there is no such problem: There is enough spare IO address space. Using almost 200 bytes of available 1024 bytes just seemed big. And I was wondering if that 1024 bytes is a hard limit. It turns out it is.

(unrelated / discussion) Available IO addressing space is something to watch out for. Some networked devices has a big footprint yet much of the space they reserve is unused. This limits the S7-1200 more than it should. Luckily I have not yet bumped my head onto the problem of running out of IO addressing space.

You have answered my main question:
The IO image does not need to be updated automatically when using SETIO / GETIO.

Having both these mechanisms active seemed to be waste of resources to me. But that is what was suggested by someone which created doubt.

Thanks for your attention to this matter.

You already have your answer.  I was going to say it like this:

Having a telegram configured should be sufficient provided the PI is configured for Automatic (updating).  No SETIO/GETIO should be necessary.

My experience with couplers is where that comes from, albeit limited to a single device.

I had to correct one of my peers who was double-dipping the telegram data.  They had a telegram configured and were manually transferring the data via DPRD_DAT and DPWR_DAT.  I showed them that simply removing the EN inputs for those blocks had absolutely no impact on obtaining updated remote inputs nor prevented sending updated outputs to the remote devices.  Several LAD networks simply got deleted and they never looked back.

I'm confused why a simple telegram is not working for your particular coupler.

I *did* have to configure the telegram data and transaction type (synchronous vs async).  Were you not given the option to configure the telegram (using some software provided by the coupler OEM)?

qwazee

Stefan Arcularius

Hi qwazee,

Sorry, it was my fault. I thought that by configuring the process image to "None", no IO addresses would be needed. But as I have now verified, this is not the case.

How many bytes of additional IO addresses would you need and how many spares do you have? Perhaps using the Publisher or Storage module type would be an option. This will allow acyclic transfer of up to 4096 bytes using only a view byte of address space. However, this increases the programming effort on both sides.

Kind regards
Stefan

Hello Stefan.

For this project there is no such problem: There is enough spare IO address space. Using almost 200 bytes of available 1024 bytes just seemed big. And I was wondering if that 1024 bytes is a hard limit. It turns out it is.

(unrelated / discussion) Available IO addressing space is something to watch out for. Some networked devices has a big footprint yet much of the space they reserve is unused. This limits the S7-1200 more than it should. Luckily I have not yet bumped my head onto the problem of running out of IO addressing space.

You have answered my main question:
The IO image does not need to be updated automatically when using SETIO / GETIO.

Having both these mechanisms active seemed to be waste of resources to me. But that is what was suggested by someone which created doubt.

Thanks for your attention to this matter.

0_Einstein

You already have your answer.  I was going to say it like this:

Having a telegram configured should be sufficient provided the PI is configured for Automatic (updating).  No SETIO/GETIO should be necessary.

My experience with couplers is where that comes from, albeit limited to a single device.

I had to correct one of my peers who was double-dipping the telegram data.  They had a telegram configured and were manually transferring the data via DPRD_DAT and DPWR_DAT.  I showed them that simply removing the EN inputs for those blocks had absolutely no impact on obtaining updated remote inputs nor prevented sending updated outputs to the remote devices.  Several LAD networks simply got deleted and they never looked back.

I'm confused why a simple telegram is not working for your particular coupler.

I *did* have to configure the telegram data and transaction type (synchronous vs async).  Were you not given the option to configure the telegram (using some software provided by the coupler OEM)?

0_Einstein, thank you for voicing your concern.

We are a sub-contractor in a multi contractor project. Another contractor is playing on his home turf. They are responsible for installing the PN/PN Coupler. They supplied a sample for the configuration and code for the data parsing. 

I assume they tested the sample. Probably we will have to open our code to them to ensure they can maintain the system for the end user. There is no strategical value to ignore what has been suggested on the use of the SETIO / GETIO instructions.

The use of SETIO / GETIO may be born out of fears about data consistency and the ease of parsing data. I will avoid the "double-dipping" effect you mentioned.

Ahh, that makes much more sense after the sub explanation.

That way, they can dictate when data can and should be updated on remote PLCs, and enforce the mechanism in code rather than simply by scan time.

Kind of like configuring ISO comms, but for s7-1200's which are not able to do ISO.  With ISO, there's an OB for reading ISO Inputs from the hardware into the process image, and / or an OB for writing ISO Outputs from the process image to the hardware.  (Or something to that effect)

It is highly scheduled, which I am assuming the SETIO/GETIO can/will be in your project.

If you configure the telegrams to update only once every 100ms, and use SETIO/GETIO as needed in OB3x, should not cause many problems.  Are they sending a single UDINT tag that increments every time the PLC updates data for the subsystem you are working on?  With that tag, you can find if dropouts or double-dipping happens.

qwazee

0_Einstein

You already have your answer.  I was going to say it like this:

Having a telegram configured should be sufficient provided the PI is configured for Automatic (updating).  No SETIO/GETIO should be necessary.

My experience with couplers is where that comes from, albeit limited to a single device.

I had to correct one of my peers who was double-dipping the telegram data.  They had a telegram configured and were manually transferring the data via DPRD_DAT and DPWR_DAT.  I showed them that simply removing the EN inputs for those blocks had absolutely no impact on obtaining updated remote inputs nor prevented sending updated outputs to the remote devices.  Several LAD networks simply got deleted and they never looked back.

I'm confused why a simple telegram is not working for your particular coupler.

I *did* have to configure the telegram data and transaction type (synchronous vs async).  Were you not given the option to configure the telegram (using some software provided by the coupler OEM)?

0_Einstein, thank you for voicing your concern.

We are a sub-contractor in a multi contractor project. Another contractor is playing on his home turf. They are responsible for installing the PN/PN Coupler. They supplied a sample for the configuration and code for the data parsing. 

I assume they tested the sample. Probably we will have to open our code to them to ensure they can maintain the system for the end user. There is no strategical value to ignore what has been suggested on the use of the SETIO / GETIO instructions.

The use of SETIO / GETIO may be born out of fears about data consistency and the ease of parsing data. I will avoid the "double-dipping" effect you mentioned.