MpIoImport limitations with long X2X chain behind X20BC0083

Ask Questions B&R Software & Runtime
1

Hello,

I am working on a project to dynamically be able to modify the HW configuration of our machines based on which machine type it is. The point I am starting from has 4-5 machine types which have IO import files pulling the modules in from Source=“AR” and changing IO where necessary based on the different machine types. This first import file works with a chain of 75 modules that live on the branch of the X20BC0083a (ik_full_p2.txt, changed extension from .xml to be able to upload):

ik_full_p2.txt (311 Bytes)

I have modified the project to no longer have the IO modules live in the physical view of the configuration because our X2X chain of possible modules got too long to successfully boot a PLC without causing an error before changing the HW configuration that we are actually running. So I am now using this type of import file which needs to call out each module individually and uses templates for the modules that were sliced from the arconfig.br and iomap.xml files in the project that had all of the modules in the physical view of the configuration(ik_full_p1.txt changed from .xml for upload):

ik_full_p1.txt (43.2 KB)

This file calls out all 75 modules that live after that X20BC0083a in the first file individually and maps IO that was originally mapped to the modules in the configuration. The problem is that this file causes issues when importing onto a real hardware setup that matches this configuration. If I include more than 53 modules (Specifically adding the SL2.IF1.ST2.IF1.ST54 X20DS438A module and commenting out everything after it) when the system powers back up the SDM shows the chain configured correctly, but EVERY module behind the X20BC0083 shows as “Not Plugged”. If I comment out the .ST54 module and only put 53 modules on the system, the SDM shows all configured modules OK. A side note is that I changed the type of module getting added at .ST54 from the X20DS438A to an X20BT9400 and it resulted in a success.

It seems like the amount of data that is getting setup for the modules when using the template files which were created by the original modules in the AS project is getting too large for implementation in this way of importing. I am wondering if there is a way to get around this and get this import to succeed. It is a critical point for the planned dynamic capabilities and if I can get past this step, I see a clear path forward.

Things I have tried so far:

  • Increase the AsyncPayload parameter on the X2X interface of the X20BC0083 from default 160 to 400.
  • Turned all Module Status info where I could in the .ar template files
  • Removed several io mapping definitions of items that do not actually show up in the IO Mapping in AS
    • i.e. NrOfResets, NrOfInits, NrOfFwUpdates, ModuleNoComm, ModuleCommError, etc.

I appreciate any feedback that might help come to a solution or help point toward this not being feasible.

2

Hi @Chad_Dossey ,
just an idea as workaround: Have you tried to change couple of predefined configurations on fly with AsIOMMan library?

image
image988×697 78.3 KB

There is an example in the help so it’s quite fast make a test and see if you have issues with this approach too, I used that example in the past and no issue.

image
image521×248 42.9 KB

Thanks
Ciao
Valerio

3

Hi Valerio,

Thanks for the reply. Our goal here is to try to eliminate the need to manage multiple configurations in the project. I was looking at AsIOMMan and I think the functionality could work as long as the config does not have to be existing in AS. I believe the MpIoImport is using these functions under the hood, so I would expect to be able to create a solution here as well, but worry that I will run into the same limitations. I may try that route in the next few days if I don’t come up with other options.

4

Normally when I work with mpIO I always remember this slice from one of my mappServices workshop:

image
image1920×1387 275 KB

Be sure your use case is covered by mpIO…

In case you don’t like the workaround with AsIOMMan, I think you should report your issue to our Support in Atlanta, it definitely required deep investigation.
You know with the CASE Support can get more details about possible limitations of MpIO, limitations that may be fixed in the next releases.

Ciao
Valerio

5

Hi all, just wanted to confirm that we have an ongoing CASE in which we are troubleshooting this issue with Chad.

6

@rafael.laury please update us with result of your investigation, thread is closed for now.

7

Hi @kovarj , thanks for the ping, we did end up finding a resolution. The root cause was that the X2X cycle time of the X20BC0083 was set to 1000 ms, which was too fast for the large amount of X2X modules connected to it. So the issue was not related to the import, but rather simply the X2X communication failing.

Increasing the X2X cycle time on the X20BC0083 to 2000 ms resolved the issue, all the modules communicated as expected after the MpIO template import.