There is a complete documentation for all KUNBUS modular gateways at the KUNBUS product pages. E.g. for Ethercat you will find the documents
here.
These documents should be answering all questions but they do of course not explain the specific fieldbus technologies. We will not publish detailed instructions about how to use a certain fieldbus technology in the near future as there are lot's of books and utorials out there explaining this part of the job. E.g. for EtherCAT you do need totally different tools to configure a slave than for ProfiBus. Such tools are standard third party products (like TIA Portal) and normally they are not very easy to use.
In short, just to give you a clue how such gateways normally work I'll explain the way for ProfBus:
A master PLC (e.g. S7) is set up by a configuration tool (e.g. TIA Portal) to exchange data with a slave (KUNBUS gateway). Therefore the configuration tool needs to read a device description file (e.g. GSD file) to get knowledge about the abilities of the slave. In our case this file tells the configuration tool that the slave is a modular slave with possible modules of 1, 2, 4, 8, and 16 byte wide IOs. You configure e.g. the slave to use 2 Modules with 1 byte input and output each. Your PLC then has 1 input byte and 1 output byte (with standard names) to use in a PLC program you need to write. This program can easily set or read this new generated input or output byte. When you set the PLC into RUN mode it will cyclically exchange these two bytes with the slave (Gateway). The Gateway holds this data in a single block for inputs and another single block for outputs. The configured bytes will be in this case the first byte of each block. If you would have configured more IO modules on your PLC they all would be one after the other positioned in the in- and output memory block.
This block is cyclically exchanged with the central process image of RevPi Core when you connect a RevPi Core to a KUNBUS Gateway. This is controlled by the RevPi Configuration software PiCtory which also defines where in the central processing image these blocks will be mirrored. With the offsets or the symbolic names o the bytes of these blocks you can then access the two bytes you've configured with your PLC using the PiControl device driver calls and Python or C / C++ or any other application sw. which communicates via our central process image (e.g. logi.RTS).
Does that make sense to you? I know that this is hard to understand and to explain but dealing with fieldbusses is always a bit tricky. We can just hide the most difficult part from you (i.e. the fieldbus protocoll itself) but you must have knowledge of how each fieldbus is structuring and accessing its IO data when you want to step into this field. It's not just like sending variables arround like with MQTT or so. Fieldbusses mostly are about exchanging cyclical IO data after having configured the master device to do so. How you configure them and how the IO data can be structured is often a highly complex topic.
Hope that gives you a clue.