In Automation Help B&R Online Help there is a section that mentioned about cross communication between iCNs where it utilizes the fact that PRes is a multicast frame so the partner iCN can directly get information from that response instead of going through MN.
Is the approach also applicable to 3rd party PLK CN (imported with XDD files)? I think technically the concept is applicable, but I am not sure if the “reading that particular frame” part is possible because it is an iCN (B&R only) or is it a common feature of PLK.
I’m not a PLK developer, but here’s what I know/think:
as you said, as PRes is a multicast, every other CN inside the same PLK domain has the possiblity to read the data from a PRes sent by a specific CN → so technically, it’s not a specific feature of the B&R iCN.
I’m not sure but I think, doing so a CN needs some extended software/firmware functionality to really read and use PRes data sent by other CNs, I can’t imagine that this is done by every CN “automatically” (because of the needed computing power and memory and so on).
Also I’m not sure how to make such a function accessible via XDD device description: maybe it depends on the standard CiA device profile, if the’re registers already reserved for such a use-case?
But even if not, in the object dictionary definition of PLK, there’s a manufacturer specific area reserved, where “non-standard communication profile things” could be implemented into the XDD handling (for such a functionality, for example by defining some SDOs for parameter data to setup the extended firmware functionality implemented in your CN).
The functionality shown in the help is predicated on the managing node and controlled nodes being in the same automation studio project (at least at a minimum being referenced together). Having all of this information in the same project lets Automation Studio build the configuration with information from the other configurations. It’s not like the binaries sent to the iCN’s have the “%IB…” information in them, in my understanding, it’s a more nuanced configuration information generated during build.
There is nothing stopping another controlled node from reading other nodes PRes. But configuring behavior like this through Automation Studio for non-B&R controlled nodes, is going to be unlikely; bordering on impossible.
I recall but don’t have an example, you can use various software libraries to pull information out of the Powerlink networks packets, or methods to have the ACOPOS read information out of a packet. So having any POWERLINK CN pull information out of a packet is possible, but dependent on the programmability of the controlled node.
POWERLINK cross traffic should be a standard feature, also a third party CN can support.
CNs supporting receiving cross traffic typically offer at least 2 sets of Rx comm parameters (0x14xx) and Rx mapping parameters (0x16xx), as well as at least a number of 2 for “PDORPDOChannels” in the GeneralFeatures of the XDD. One for the MN PREQ, one for a related PRes of an other CN. (Not sure if the “CNFeatures” section also needs to contain information regarding to that…)
Maybe you could just try to configure the cross traffic mapping in AS and see if it works for you.
It is similarily configured as it is documented for the iCN: find an ouptut channel of the third party CN and try to map an input channel of an other device. Data types have to match though.
