Page 1 of 2
DeviceNet sniffing
Posted: 23 Aug 2018, 11:41
by ulrich06
Good morning,
My company is involved in an Industry 4.0 project to collect and analyze data from production lines. These production lines contain several devices connected to a DeviceNet bus.
We ordered several RevPi and Gateway DeviceNet devices and successfully installed them on the different lines.
Since we are working on existing lines, we want to be the least intrusive on the network and therefore want to use the bus to "sniff" the data (i.e. we do not want to register with the Master).
We encounter difficulties to accomplish this with the DeviceNet Gateway since we do not have access to the communication part (we can only read/write values stored in the memory through /dev/piControl0). Is there a way to be able to read all the data passing on the bus (like a promiscuous mode or a with a 10$ CAN-USB adapter)? Also, we did not find any code showing the collection loop at the Gateway.
Finally, we have found /dev/serial0 and /dev/ttyAMA0 interfaces in the RevPi core, what do they correspond to?
Thanks in advance for clarifications,
Cyril
Re: DeviceNet sniffing
Posted: 24 Aug 2018, 16:47
by dirk
The DeviceNet Modular Gateway Module acts as a slave that reads and writes I/O data between fieldbus and the RevPi. Therefore the Gateway Module exchanges data on the fieldbus with a fieldbus master. There is no raw data access or promicious mode possible. On the RevPi you have the process image. Here the I/O data from the Gateway is stored and cyclic updated via the so called PiBridge and the
PiControl driver. You may access the data by C, Python, Node Red, etc... So if there is a master that sends data to the Modular Gateway you can access the data through the process image.
The /dev/serial0 is a symbolic link to /dev/ttyAMA0. These are devices to access the UART0 interface on the RaspberryPi Compute Module (CM). Here in the
schematic of the RevPi you can see that the UART0 is connected to "PB_RS485". This is the RS485 interface of the PiBridge.
Re: DeviceNet sniffing
Posted: 27 Aug 2018, 09:07
by ulrich06
Hello Dirk,
Thank you for your reply and for the explanations.
The schematics are very useful to understand how the Core platform is built but I can't find the ones related to the gateways, are they available?
Also, I browsed the Kunbus's GitHub looking for the embedded code in gateways, but without success. Our idea would be to embed a custom firmware in the gateway so that it can relay all data passing through the communication interface to the core module.
Thanks
Re: DeviceNet sniffing
Posted: 27 Aug 2018, 15:35
by dirk
The Gateway Modules are not part of the RevPi open source platform. So the code and schematis are not public. But I have good news for you. Together with the new
RevPi Connect Module we have the CON CAN Module. As DeviceNet is a subset of CAN we have tested your idea to sniff the raw CAN traffic - and it works well. We have tested also with Node Red by using the Node Red Contrib Canbus library - works like a charm.
So to start with this you would have to get a CON CAN Module and a RevPi Connect (not a RevPi Core 1 or 3). If you want to pre-order just send a mail to
sales@kunbus.com because the modules are so new that they are not yet available in our online shop.
Re: DeviceNet sniffing
Posted: 27 Aug 2018, 19:12
by ulrich06
Ohh... That is confusing with your frontpage stating "
Open Source IPC based on Raspberry Pi" and your motto "Don't claim it, make it"
Is the CON CAN Module closed source as well?
Is it only compatible with a RevPi Connect? (which would be quite disappointing after purchasing and deploying several RevPi Core 3)
Re: DeviceNet sniffing
Posted: 28 Aug 2018, 10:13
by dirk
Dear Ulrich06,
the Gateways are part of the KUNBUS product portfolio for industrial communication. They have been existing before we started the RevPi Project. We saw benefit for the platform to connect to these modules and created the interface you know as PiBridge.
Communication modules are closed source as they contain protocol stacks which we developed ourselves or purchased from other vendors, thus IPR we cannot disclose. These modules are and have to be certified by the user organization behind such protocol (e.g. PI/formerly PNO for Profinet).
In regards to your second question the RevPi Connect is a new variant of the RevPi platform, which we developed based on customer feedback and forum request. In order to achieve the desired functionality for new extension modules such as the CON CAN Module, we had to adapt the interface between the modules. The result is the new CONBridge. RevPi Connect provides a standard PiBridge interface (to the left) in order to use IO Modules and Gateways. The CONBridge is a new way of connecting modules using simple interfaces like SPI and direct power supply. This involves a physically different pinning in the plug. The CON CAN Module requires this new interface hence it works with RevPi Connect only. Furthermore, RevPi Connect Modules provide additional benefits like two separate Ethernet interfaces, following the request we received in this forum.
To discuss options for your previous purchases, please kindly make contact with our sales team.
Thank you
Re: DeviceNet sniffing
Posted: 25 Mar 2019, 03:16
by namo
Hello Dirk-san,
I am trying to sniff the DeviceNet, too.
Reading this topic, I purchase CON CAN Module and RevPi Connect.
Regarding "CON CAN Module and RevPi Connect with Node Red by using the Node Red Contrib Canbus library" , I would like to know the port set up of can.
May I have any advice, please?
Thanks.
Re: DeviceNet sniffing
Posted: 08 Aug 2019, 17:15
by Eduard
Please watch the tutorial
here.
Re: DeviceNet sniffing
Posted: 29 Aug 2020, 13:29
by cataliz3er
Hey guys, I didn't find any other relevant posts and if needed I will create a new one, but I thought here would be a good place to post this question.
I just bought a RevPi Connect + DIO + DeviceNet Gateway and what I would like to do is connect the inputs/outputs from the DIO to the Gateway. I need this in order to interface sensors and actuators with a KUKA robot.
I'm finding it very difficult to find any detailed documentation on how to achieve something like this and now I'm beginning to wonder if it's even possible.
I eventually managed to find a user manual on a distributor's website.
I have 2 leds flashing red:
POWER = Correctable error (e.g. second gatewaycomponent missing)
MS = At least one system component is not running due to a configuration error or the partner gateway component is not connected.
Any info is much appreciated!
Thanks!
Re: DeviceNet sniffing
Posted: 03 Sep 2020, 14:19
by cataliz3er
Connected the gateway to the Kuka KRC2 Controller. Now the NS LED is on green but the other two are still flashing.
https://youtu.be/btVILZy-sPw