Gateway Packets

[imuguruza]

Hey there,

I would like to know if it's possible to see at the PiCore the packets of the different networks I have access thank to different gateways. For example, I would like to see which CAN packets are going around in the CANopen bus or at the EtherCAT bus. How can I make this stuff??

Also, would be great to have some examples about how can we work under this busses, because, right now, the examples are about IOs.
Thanks in advance,

imuguruza

[volker]

Hi Imuguruza,
you need to configure your gateways in PiCtory. In PiCtory you do have a bunch of bytes for input and another bunch of bytes for output for a gateway. These bytes are exchanged on the fieldbus cyclically. E.g. if you have a Profibus gateway, the gateway is a modular Slave device to the Porfibus Master. The GSD file enables you to sentimentalize the data into 1, 2, 4, 8, or 16 bytes large modules which on the RevPi side of the gateway are always one single block of data in the central processing image. So your PLC-SW (e.g. logicals) or any C or Python program can access this data as a whole block by use of PiControl driver IO. IN case of Profibus you will not find bus messages in this block but IO data which the Profibus master has send to the modular Slave device (i.e. the Gateway module) but you will find a continuous block of bytes which you can interpret with your application sw (logicals or any other).
Does that make sense to you?

[imuguruza]

Hi,

First of all, thanks for your fast answer. It makes sense, if I got it you mean that I will not have access to the specific bus I'm working under but to the defined data at the configuration. How can I import those variables in Python? Any example I could have a look?

imuguruza

[volker]

Try to get an idea with video tutorial #16 in German (we do not yet have them in English). Or get the source code for this video tutorial from support/download section.
In Tutorial #13 PiTest is explained which is C code for accessing the central process image. (it can be downloaded too). I fanything is not clear, just post your question and we'll try to sort it out..

[imuguruza]

Great, so I would like to read a variable that comes from other device through the EtherCAT bus. How can I do this? I'm able to read the Revolution Pi EtherCAT Gateway variables using the LightSwitch code.
But how can I write a variable and send it through the network? Same with reading, how can I read?

In case of writing, is the same as the example?

Code: Select all

					sValueOut.i8uValue = ~sValueOut.i8uValue;
														// PiBridge - set output pin
					i = piControlSetBitValue(&sValueOut);
					printf("%-32s : %s \n", pchOutput, sValueOut.i8uValue );
					if(0 != i)
					{
						fprintf(stderr, "Error: piControlSetBitValue() returned %d\n", i);
						return -1;
					}

**EDIT**

I'm attaching the code i would like to use. The purpose would be just trying to read at "Input_1" the variable value that another device has changed and change the value of "Output_1" and spread it through the EtherCAT network.
Here you have it:
https://gist.github.com/imuguruza/74a67 ... 091a4a1690



imuguruza

[volker]

Hi,
your posting gives me the impression that there might be some basic misunderstandings.
Like in most Fieldbusses EhterCAT needs a master device whisch mus be programmed to exchange data with the slaves. Normally this would be a PLC with a controlling application sw. This sw would be responsible to say what data is exchanged when with the slave device. Our EtherCAT Gateway is a slave device. It simply waits for the EhterCAT frame from the master and responds to it by sending and receiving data from its internal data storage. The RevPi process image data is cyclically exchanged with this Gateway data storage (they are kind of mirrored). When and what data is exchanged with other Fieldbus-members is never controlled by the slave (the gateway module) but always by an attached master device (e.g. a Beckhoff PLC).
Does that make any sense to you?
If you are missing more information about fieldbus data exchange please refer to wikipedia articles explaining EtherCAT or other fieldbusses. It's a complex topic which needs inside knowledge of the fieldbus telegrams to understand how you could possibly exchange data between EhterCAT devices and the RevPi Core. First of all you need to sort out who will be master in your setup and how you are going to program it in order to get data from slave devices.

[imuguruza]

Well, you're right I messed up some concepts. Even that, I think that as there's lack of documentation how to do it. I don't really get how can I send simple variables to the EtherCAT gateway, how this EtherCAT abstraction works. When do you plan to release docs about how to use different field buses??

imuguruza

[volker]

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.

[KarlZeilhofer]

Interesting discussion.
As Kunbus is promoting RevPi as a PLC, are there any plans to access all the field busses as a master?

[volker]

We plan to release Modbus and ProfiNet as sw stack solutions (incl. configuration tool) at HMI in April. We also close to release of Ethercat and other masters as Gateway modules.