canopen
canopen copied to clipboard
Socketcanopen vs Canopen
What is the difference between socketcanopen and canopen? Are they interchangeable?
Hi @amostafa9,
What examples ??? CANOpen is a communication protocol, and i think you want to say SocketCAN, that is a "generic" CAN driver for Linux that provides the communication interface. You can configure the CANOpen to use different drivers such as socketcan, kvaser and others (see this link)
From readthedoc:
network.connect(channel='can0', bustype='socketcan')
# network.connect(bustype='kvaser', channel=0, bitrate=250000)
# network.connect(bustype='pcan', channel='PCAN_USBBUS1', bitrate=250000)
# network.connect(bustype='ixxat', channel=0, bitrate=250000)
# network.connect(bustype='nican', channel='CAN0', bitrate=250000)
The CANOpen API uses the SocketCAN driver as a interface through python-can to communicate with the CAN bus network.
Thanks for the response. I was thrown off a bit by this repo: https://github.com/bggardner/canopen-rpi Looks like this also uses socketcan but specifically for the RPI. I guess it still uses the CANopen for python API as its library for CANopen?
The examples i was referring to were on that github page.
I don't know that API ... But like a said, CANOpen is a protocol, SocketCAN is a "generic" driver for Linux that enables the communication with the CAN bus network.
From the readme file from the canopen-rpi
socketcan, abstracts the CAN interface by providing Bus and Message classes. The socketcan module can be used to create adaptors to translate CAN traffic to other protocols. The second module, socketcanopen, contains classes to instantiate a CANopen node application. Each node must be initialized with at least one socketcan.Bus, a node ID (integer, 1 to 127), and an socketcanopen.ObjectDictionary.
Is exactly what i said, socketcan for access the CAN bus network and socketcanopen implements the CANOpen protocol, the name perhaps is confusing ...
This API (i.e., the canopen API) provides the implementation for interaction with CANOpen enabled devices, supporting the CiA 301 and DS-402 profile.
Thank you. Another question. Is there slave support with this API? How can I instantiate a slave? If there isn't slave support, how can I at least implement slave functionality with this API? Thanks for the help.
No problem.
Slave nodes are supported but limited, you can instantiate a slave node by using the LocalNode class. For more information regarding the state of the implementation check #47 . At this point, this library is meant to be used as a master controlling slave nodes, but you are welcome to start tinkering with the code and help improving the support for slave nodes locally. Good hacking ;)
The socketcanopen
Python module (which I developed independently from this repo), is targeted for creating both masters (including flying masters) and slaves using the same Node
class. Nodes
are attached to the bus at initialization, so no Network
classes or subscribing is needed. I just changed socketcanopen
to use python-can
instead of my now-deprecated socketcan
module. I have some examples of slaves and masters. However, testing has been limited to using socketcan drivers.
I would love to merge the features of the two repos into one (preferably this one), since it's already registered in PyPI. I'll post an update here if/when I create a fork.