Hi All,

I'm using CodeSys on a Raspberry Pi.
I successfully use the CANbus library/module to read an write messages using SocketCAN and an attached CAN-hardware (MCP2518FD)

in CodeSys I use:
can0: CAN.CANBus_11bit

the driver is initialized with the following config:
can0Config: CAN.DRIVER_CONFIG := (usiNetwork := 0, uiBaudrate := 500, ctMessages := 200);

the driver is opened/started with:
can0(DriverConfig:= GVL.can0Config, eError=> );

...and as mentioned initially: everything works - almost!

the very strange thing is, that I can successfully send and receive messages between codesys and my hardware - but when I use the "candump can0" command to monitor the messages on SocketCAN on my raspberry, I miss all the messages sent from codesys (to the hardware). all the incoming messages (hardware to codesys) are there.
test-messages sent using "cansend can0 ..." successfully reach both ends: codesys and my hardware

it seems to me somehow as if calling "can0.SendMessage()" from codesys bypasses SocketCAN on the raspberry and writes directly to the hardware (which isn't really possible as the hardware (kernel-)driver on the RasPi is directly linked with SocketCAN).

again:
"can0.ReceiveMessage(..)" can see both: messages from the hardware and (test-)messages created using "cansend can0 ..."
"can0.SendMessage(..)" only sends to hardware. these messages are NOT seen on SocketCAN ("candump can0")

...any ideas?
is there an option to enable "mirroring" the sent messages on SocketCAN?

thanks for your help!

Hi,
I would use the compiler define (in CODESYS on the Application) CANOPEN_DEBUG to have all this SDO's in the plc logger to analyze the CAN problem with the network. ( Guess this is what try to do?)

I'm not really sure if this setting in /etc/CODESYSControl_User.cfg:

[CmpSocketCanDrv]
Loopback= 1
would help - but even if so, remove it later after finishing this dump investigations.

BR
Edwin

thanks Edwin, adding
[CmpSocketCanDrv]
Loopback=1
in /etc/CODESYSControl_User.cfg does the trick...

still - two questions remain:

1) why isn't that enabled by default?
IMHO SocketCAN behaves just like a (hardware-)bus: everything that is on the line should be seen by every device attached to it.
what reason is there that the CodeSys-CanDriver even has the option of disabling this behavior at all?!

2) why do you advise do "remove it later after finishing this dump investigations"?
I actually do need the CodeSys-sent messages internally on SocketCAN as I need to process and handle some messages by a service running on the RasPi

thanks again,
Hannes

ok, I googled a little bit on this topic:
SocketCAN documetation on kernel.org reads:

  4.1.3 RAW socket option CAN_RAW_LOOPBACK

  To meet multi user needs the local loopback is enabled by default
  (see chapter 3.2 for details). But in some embedded use-cases
  (e.g. when only one application uses the CAN bus) this loopback
  functionality can be disabled (separately for each socket):

    int loopback = 0; /* 0 = disabled, 1 = enabled (default) */

    setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));

so again:
WHY does CodeSys' CanDriver not use the default setting of 1 (=enabled) per default?
no one can (or should!) assume, that only one application uses the CAN bus!

come one, this is not really true, default is only CODESYS use the CAN ;-) what is your use case then?
Just dump to check if all telegrams are in or what is the second application?
To be honest.. on most devices only CODESYS use the CAN as I know. ( Maybe I'm wrong)