HI,
first of all let me say we deeply regret being late with the English tutorials. Our aim was to get the German stuff translated as soon as it is written. But our translation service is not as quick as we hoped. So right now we are trying to find alternatives to get really good translations of the German material in time. You could perhaps try to get a good start by reading the complete blog starting with the first article at the bottom. We have explained lots of details in the blog and it is completly translated into English. The 4th article from August 11, 2016 is about the gateway modules.
However - I will at least try to give you a short explanation of the gateway modules...
These modules are working all the same way: They have an internal memory area where data to and from cyclical fieldbus trafic is stored. This area is 512 byte in and 512 byte out for most of the modules. This data is cyclically exchanged with the filedbus master according to the specific fieldbus protocol. The master (mostly a PLC, in your case an
Ethernet/IPmaster like a Rockwell PLC) could have insight to the meaning (semantic) and structure of the data but the gateway does not care about such structure or semantic. It simply collects the data as a anonymous continuous block of bytes (module input) or uses such a block of bytes to send it onto the fieldbus (module output). Therefore there is normaly nothing to configure with a gateway module. The configuration is all done on the fieldbus master (PLC), e.g. TIA portal for a ProfiNet master. You need to tell the master to use the module as a slave device and to exchange data with that device. This is something we cannot explain for you because it is something depending on you specific master and the configuration tool you are using to configure your master device.
When you connect a gateway module to a RevPi Core usingh the PiBridge the PiConnect Kernel driver will automatically mirror the data memory of the gateway module into the RevPi Core's process image. This is again a memory area which is reserved for input an output data collected over the PiBridge. The mirroring is done cyclically with a cycle time between 10 and 40 ms (depending on your systems's configuration) and is asynchronous to the cyclical fieldbus communication which is controlled by the fieldbus master (PLC).
Any application software running on our RevPi Core may access the process image using the PiControl driver APi which Linux file based ("open", "seek", "write", "read", "close" and "ioctl"). This application software may use the data in a structred way if it has knowledge about the semantic (e.g. putting 4 bytes together to form a real number or using single bits of a byte as boolean etc.).
Logit.RTS (the runtime sytsem of Logi.CAD3 is cyclicalle reading and writing data to the process image of RevPi Core. Thus it may access the mirrored data from any gateway module. You need to use the ST editor (for free) or the FUB editor to write your controll software like with any ordinary PLC. in order to access the process image you simply need to use the ST declaration import function to impiort the PiCtory process image information to your controll application (the deitor does offer you such a possibility). After doing so you would have n bytes input and m bytes output to be used by your control application. The ST declaration imnport will tell logi.RTS at which offset these bytes are located. You could simply change the declaration to combine several bytes to form a real or any other data type or to access single bits of a byte using the common ST declaration syntax for inputs and outputs. I know this sounds a little complicated but it is a very versatile and felxible way to interface the different systems using just byte offsets and leave the task of forming other data types to the way you use these offset information.
In PiCtory (this is our graphical configuration tool running on a webserver of the RevPi Core) you simply drag and drop the gateway module from the module list to the desktop and click on the export options for n and m bytes offered in the data section. You could also give any of them other names but the defaults. But you cannot structure the data in any way using PiCtory. Once you have saved your PiCtory configuration the process images's data offsets are listet in an ST declaration file stored on the RevPi Core and being accessed by PiControl or the Logi.CAD imort function.
So the circle is completed: You start with n input bytes and m output bytes on the Ehternet/IP master, exchange it with the RevPi gateway slave module and it will end upo in you Logi.RTS system where it can be used for your control application.
Hope this helps to understand how the gateway mechanisms are working. If you want to play arounf with the logi.CAD3 editor you can download it for free in our shop. The logi.RTS is also free but will need a system reset every hour if you have not installed the licence key file. The FUB editor is not for free and there is no trial version of it. You can get a feeling of how to use it on the manufacturer's web site (logi.cals).