Step-by-Step Documentation/Video for Ethernet/IP Gateway

[mandeepahuja]

Hello Revolution Pi Team,

I am looking to buy and try out the RevPi 3 Module with the Ethernet/IP Gateway. I have not been able to find good documentation (mostly German) in English on the website that explains Step by Step how to configure the Core Module and Ethernet/IP Gateway and write the structured plc code. I understand the gist of it but need clear documentation and examples.

Something along the following lines
1. How to Setup the hardware RevPi 3 with Ethernet/IP Gateway
2. How to Setup in Pictory
3. How to Setup and program in logi.CAD3. An example should help
4. How to download and execute on RevPi 3

Please let me know

[volker]

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 anEthernet/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).

[mandeepahuja]

Thank you for the detailed explanation!

I was under the impression that I can eliminate the Rockwell PLC and use the RevPi core as a PLC with being an Ethernet/IP Master? Like I can do with Codesys.

[volker]

I' m sorry but we (not yet) offer any Ethernet Master stacks (except the Modbus TCP). Our gateway modules are all slave modules so you cannot use the RevPi Core to replace an Ethernet/IP master.
We already have a master stack but the configuration tool is under construction and will take some time until we can offer the stack for the RevPi Core...

[gb0815]

Hi everyone,

I'm also very interested in a EtherNet/IP Master feature. What is the current status of this feature running in RevPi?

Regards
Gerold

[volker]

If you install Codesys for Raspi on our RevPi you get Ethernet/IP master functionality. But actually there is not a very smart way to access our IO Modules with Codesys. We are working together with Codesys to change this but there is not yet a reliable time schedule. Until then you could only use the build in Modbus master of RevPi to cyclically exchange data with the Codesys Modbus slave. When you add a little python script to copy IO data in our process image to the modbus master bytes in the process image you get the IO data accessible in the modbus slave of Codesys - voilá you have it in the Codesys process image. Not very high performance but at least a solution.
And yes, we have tried this and it works fine - also with EtherCat...

[mirko.comparetti]

From pictory, how can I get the esi file for ethercat? So that I can import it in the ethercat master.
Also, in pictory I only see 20 in and 20 out as byte... I expected them to be more and with the possibility to use words, ...

Thanks!

[dirk]

You may download the ESI file and the user manual from here. The Gateway Modules work like shared memory. So you have I/O in the process image and you may use PiCtory to rename your data according to your needs. Initially there is Input_1, Output_1, etc. So you may access this data with

Code: Select all

piTest -r Input_1
piTest -w Output_1,123

The data is stored internally in the little-endian format so you have to interpret a 2-Byte value at offset 0 using Input_1 and Input_2. The Ethernet/IP Gateway supports up to 480 bytes of process data. See chapter 5 in the user manual for the details.