I suggest to the developers to seriously think about making CAN/CANOpen supported in some way or another too.
Both for educational purposes (for the "Teaching" part in "Raspberry Pi Teaching Platform") and for purposes of actually using this in automotive and other fields, where CAN slaves are either already present as a standard or cheaply available.
ProfiBus/Profinet solutions on the other hand tend to be rather expensive (compared to CANOpen counterparts) due to licensing etc. At least in my personal experience.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And its also easy to build your own messages to communicate on a higher layer protocol (thinking of J1939 and CANopen(if just sharing PDO) )
I played a little bit with codesys 3, i use Codesys 2.5 at work everyday, i think the J1939 Library seems pretty awesome, it gives you the latitude to configure custom messages wich is good, but could we get to lower layer with the pi and just send and recieve raw CAN messages?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While working woth codesys 3.5 on the new ECU I'm using at work, I understood that if the CAN driver is integrated at the system level you can use it directly in codesys with the low-level coding.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
if anyone manage to build his own Linux kernel with socketcan support,
this will work with the 3S runtime. The needed parts in the runtime are in.
And if you have socketcan running, even J1939 will work out of the box, everything needed is on board in CODESYS IDE
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=17:pd=20:pds32-0=10000000:pdu32-4=0x2002:force_release
modprobe spi-bcm2708
modprobe can
modprobe can-dev
modprobe can-raw
modprobe can-bcm
modprobe mcp251x
ip link set can0 up type can bitrate 250000
service codesyscontrol start
What I can not get working is CoDesys to recognize the PI to have CAN. Whenever I add the CanManager it will give me compile message that the hardware does not match the controller.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As requested here are the attached log files. To give you more info I am still using demo version codesyscontrol_V3.5.4.0.deb. I also noticed I was not loading all the modules required for SocketCan. Please notice I updated the steps up above along with the Dmesg output screenshot. Also I do not load the codesyscontrol service until all modules are loaded. Let me know if you need any further information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Same problem using CODESYS_3.5SP5Patch1_Release and Raspberry Pi CoDeSys Control Version: 2.0.0.0 aka codesyscontrol_arm_raspberry_V3.5.5.0.deb. See Attached PLClogs. FYI I know cansocket is working because I can use candump and monitor traffic off a PLC with CanOpen master.
Do you have to add any additional components under ComponentManager section in CODESYSControl.cfg?
If you have a running SocketCAN implementation in your Linux Kernel, this should work.
(This is not the case in the delivered standard wheezy image which comes with the store download!)
Regards
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I can download to the PI without error but Canbus still does not work. See attached PLClog. It gives Script: rts_set_baud.sh not found- can 0 will not work.
With CanSocket I bring up the Canbus and match the bus speed used in the Codesys program. This is the command I use to bring up the adapter:
ip link set can0 up type can bitrate 250000
Also I have disable the Codesyscontrol service on boot up. If I don't CanSocket will not load because Codesyscontrol locks control. I believe is caused by Codesyscontrol locking out SPI driver. If I load CanSocket first then start Codesyscontrol it will let me download but as above Can still is not working.
beside the problem with the baudrate script, which we could workaround with using the same baudrate as you set with ip link set can0 up type can bitrate 250000.
This line with the missing license file may lead to the read triangle in the device tree on the left side and maybe to an
not working CAN.
How do you start the plc manually it seems that the runtime does not find the licensefile?
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am still using the demo version. I can purchase a license if required. Right now I am playing with different images and different PI's. My plan was to buy a license once I get Canbus working. This way I do not have keep moving the license when using a new image or PI.
I have to done the following:
#1 Disable codesyscontrol at boot up
#This was required because CanSocket does not want to load if codesyscontrol is first loaded
sudo update-rc.d codesyscontrol disable
reboot
#2 Load all required drivers and start CanSocket
modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=17:pd=20:pds32-0=10000000:pdu32-4=0x2002:force_release
modprobe spi-bcm2708
modprobe can
modprobe can-dev
modprobe can-raw
modprobe can-bcm
modprobe mcp251x
ip link set can0 up type can bitrate 250000
#3 Start codesyscontrol
service codesyscontrol start
#4 From windows download the codesys program with Canbus->Canopen Manager
#5 Start PLC from windows codesys
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
no, you do not need to purchase a license, but please use 3.5.5.0 because then you have the same
version that I use and in my case I do not see the error in the log: license file missing - License File missing -> think fieldbus will not work
even not in Demo mode.
The limitation of the demo pi runtime is:
All fieldbus feature are running but the runtime quits after 2h of working in full mode.
So for sure you do not need to buy a license for our tests.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The error in the log: license file missing - License File missing only happens when I modified the /etc/CODESYSControl.cfg with the CanBus lines. If take out the CanBus in the codesys program and I comment out the lines below and restart the codesyscontrol service it does not have an error. See attached screenshot.
#/etc/CODESYSControl.cfg CanBus commented out [ComponentManager]
Component.1=CmpOpenSSL
;Component.2=CmpCAACanL2
;Component.3=CmpCAASdoServer
;Component.4=CmpCAASdoClient
;Component.5=CmpSocketCanDrv
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. Let me know if you need remote access to my PI.
Also if the creator of the pre-compiled modules would also compile the virtual driver, true hardware would not be required for testing. I did not have the time to set up a cross compiler to compile the modules myself. I will try to e-mail the creator if he would also include the virtual driver.
jzhvymetal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tested this now,
to be honest not with MCP2515 (because my hardware seems to be somehow broken)
I've used Peak CAN Dongle but this makes no difference both are based on socketcan.
How does it work:
You need to copy the rts_set_baud.sh to the /root/ directory and make it executeable by chmod +x rts_set_baud.sh
#!/bin/sh
CAN_NUM=$(echo $1 | sed 's,^can([0-9]).,\1,')
./pcan /dev/pcanusb$CAN_NUM $2
(In case of MCP2515 check if you need to modify it slightly)
For other users reading this post:
For using peak usb can or MCP2515 CAN interface it is needed to compile the kernel and enable CAN and the modules/interfaces which you want to use. This is the missing part - but we could not add this to the standard store image - because
there is a lot of effort to test it and the experience till now was that on high load you might loose CAN Messages.
now additional for others and you the description how it works with MCP2515 PICan interface. @jzhvymetal skip the parts with the kernel update.. you need only the scripts to set the baud and the start the runtime after loading the can modules. http://skpang.co.uk/catalog/pican-canbu ... -1196.html
sudo modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=25:pd=20:pds32-0=16000000:pdu32-4=0x2002:force_release
sudo modprobe mcp251x
sudo ip link set can0 up type can bitrate 250000
sudo ip -s -d link show can0
At this point CAN works now (under Linux Wheezy)
What is additional needed to run it in the CODESYS runtime:
then for testing purpose add a script in /home/pi
startplc.sh (this is needed for have the right start order.. 1. load modules .2 start plc)
#!/bin/sh
sudo /etc/init.d/codesyscontrol stop
sudo modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=25:pd=20:pds32-0=16000000:pdu32-4=0x2002:force_release
sudo modprobe mcp251x
sudo ip link set can0 up type can bitrate 250000
sudo ip -s -d link show can0
sudo /etc/init.d/codesyscontrol start
this stops the runtime
load the modules
and starts the plc again
additional you need a script in the runtime directory (in our case /root)
cat /root/
rts_set_baud.sh
#!/bin/sh
BITRATE=expr $2 \\* 1000
ifconfig $1 down
echo ip link set $1 type can bitrate $BITRATE
ip link set $1 type can bitrate $BITRATE
ifconfig $1 up
Let's see if this work for you and others too
and let's see how stable the implementation is (according of losing messages etc)
I am still having trouble with the CAN SPI model with codesys. I can get the can SPI working directly from the console and able to send message to my PeakCan usb adapter.
As soon as I start the codesyscontrol by typing the following "service codesyscontrol start" the Can adapter drops out. If I type ifconfig the can0 is no longer listed. Also if type dmesg I get the following output that repeats
[ 482.345440] mcp251x spi0.0: MCP251x didn't enter in conf mode after reset
It looks like when I run the codesyscontrol service it trys to reinitialize SPI causing the CAN apapter to drop out.
Also you no longer have to use the older Raspbian 3.10.22+ there is a new complied version of the drivers for the latest kernel Raspbian 3.12.28+ (http://lnxpps.de/rpie/)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got CAN Bus working. The problem was the GPIO pins for the interrupt for mcp251x (GPIO17 in my case) and for some reason GPIO04 need to be disabled in the Codesys program. Also every time you do a full download it will reinitialize the GPIO pins which causes the CAN SPI module to stop working. This does not happen if you disable all the GPIO pin in the Codesys program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some good news to report. The modules for SPI and MCP251x are buggy in the tree. The good news is there are updates outside the main tree that fix the problems.
After compiling and updating the kernel and modules, CanBus has been going no stop for the 2 hour demo (Still have not purchased a license). I was able to have a 1ms cyclic with data changing on a remote I/O(OTB) every 5ms. This was done by having the output wired directly into an input on the remote I/O unit(OTB). See the attached screenshot
Attached is a procedure to cross compile all modules/kernel/canutils using Ubuntu. Also provided is the compiled modules for the current latest kernel.
I did a stress testing using the CanEcho program and USB PCAN adapter. Running the 1ms cyclic task for the CanEcho program and had PCANView sending every 2ms with CanBus set for 250kbps. The results show that every transmission was echoed by the PI with no drop outs for 8hours and still going. I just can not explain why the PI transmitted more message than the PCAN transmitted. Any case I am impressed by the results. This was done with a non-optimized PI without overclocking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there(or will there ever be?) any mean to use CAN with an expansion board like this one : http://www.industrialberry.com/can-controller/
with the raspberry pi and CodeSys?
I think this would be a pretty awesome feature
Also is there any mean to programm custom SPI libraries(i'm thinking of making an ADC board and use analog inputs in codesys logic)
THanks for this great product!
I suggest to the developers to seriously think about making CAN/CANOpen supported in some way or another too.
Both for educational purposes (for the "Teaching" part in "Raspberry Pi Teaching Platform") and for purposes of actually using this in automotive and other fields, where CAN slaves are either already present as a standard or cheaply available.
ProfiBus/Profinet solutions on the other hand tend to be rather expensive (compared to CANOpen counterparts) due to licensing etc. At least in my personal experience.
And its also easy to build your own messages to communicate on a higher layer protocol (thinking of J1939 and CANopen(if just sharing PDO) )
I played a little bit with codesys 3, i use Codesys 2.5 at work everyday, i think the J1939 Library seems pretty awesome, it gives you the latitude to configure custom messages wich is good, but could we get to lower layer with the pi and just send and recieve raw CAN messages?
While working woth codesys 3.5 on the new ECU I'm using at work, I understood that if the CAN driver is integrated at the system level you can use it directly in codesys with the low-level coding.
Hi,
if anyone manage to build his own Linux kernel with socketcan support,
this will work with the 3S runtime. The needed parts in the runtime are in.
And if you have socketcan running, even J1939 will work out of the box, everything needed is on board in CODESYS IDE
BR
Edwin
Edwin,
I managed to find a SPI Can Module that works with the PI
http://www.mikroe.com/click/pi-shield/
http://www.mikroe.com/click/can-spi-3.3v/
Using the following I got the SPI to show up as an socketcan adapter by using the following steps
http://lnxpps.de/rpie/
http://tech.enekochan.com/en/2014/03/08/upgradedowngrade-to-a-specific-firmware-kernel-version-with-rpi-update-in-raspbian/
#Need to downgrade to match copied modules raspberrypi 3.12.22+
sudo rpi-update bfd37013c701f10c6df585346ee1d3d3bdf88b3b
cd /tmp; wget http://lnxpps.de/rpie/rpi-can-3.12.22+.tar.bz2
# untar the archive:
cd /; sudo tar jxvf /tmp/rpi-can-3.12.22+.tar.bz2 # you normally should'nt do that
# register modules:
sudo depmod -a
# and do a
sudo reboot
modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=17:pd=20:pds32-0=10000000:pdu32-4=0x2002:force_release
modprobe spi-bcm2708
modprobe can
modprobe can-dev
modprobe can-raw
modprobe can-bcm
modprobe mcp251x
ip link set can0 up type can bitrate 250000
service codesyscontrol start
What I can not get working is CoDesys to recognize the PI to have CAN. Whenever I add the CanManager it will give me compile message that the hardware does not match the controller.
Thanks
Hi,
Thanks for reporting this,
could you give me the messages from the plc log?
Regards
Edwin
Edwin,
As requested here are the attached log files. To give you more info I am still using demo version codesyscontrol_V3.5.4.0.deb. I also noticed I was not loading all the modules required for SocketCan. Please notice I updated the steps up above along with the Dmesg output screenshot. Also I do not load the codesyscontrol service until all modules are loaded. Let me know if you need any further information.
Hi,
please use the 3.5.5.0 version of the runtime, then it might work, to be honest I did test it but I will do it.
Best regards
Edwin
Same problem using CODESYS_3.5SP5Patch1_Release and Raspberry Pi CoDeSys Control Version: 2.0.0.0 aka codesyscontrol_arm_raspberry_V3.5.5.0.deb. See Attached PLClogs. FYI I know cansocket is working because I can use candump and monitor traffic off a PLC with CanOpen master.
Do you have to add any additional components under ComponentManager section in CODESYSControl.cfg?
PlcLog 3.5.5.0.xml [22.59 KiB]
codesyscontrol.log.V3.5.5.0.txt [16.18 KiB]
Hi,
you need to add the Component 2-5 into
/etc/CODESYSControl.cfg
[ComponentManager]
Component.1=CmpOpenSSL
Component.2=CmpCAACanL2
Component.3=CmpCAASdoServer
Component.4=CmpCAASdoClient
Component.5=CmpSocketCanDrv
If you have a running SocketCAN implementation in your Linux Kernel, this should work.
(This is not the case in the delivered standard wheezy image which comes with the store download!)
Regards
Edwin
Edwin,
Now I can download to the PI without error but Canbus still does not work. See attached PLClog. It gives Script: rts_set_baud.sh not found- can 0 will not work.
With CanSocket I bring up the Canbus and match the bus speed used in the Codesys program. This is the command I use to bring up the adapter:
ip link set can0 up type can bitrate 250000
Also I have disable the Codesyscontrol service on boot up. If I don't CanSocket will not load because Codesyscontrol locks control. I believe is caused by Codesyscontrol locking out SPI driver. If I load CanSocket first then start Codesyscontrol it will let me download but as above Can still is not working.
PlcLog.xml.txt [17.36 KiB]
Hi,
beside the problem with the baudrate script, which we could workaround with using the same baudrate as you set with ip link set can0 up type can bitrate 250000.
This line with the missing license file may lead to the read triangle in the device tree on the left side and maybe to an
not working CAN.
How do you start the plc manually it seems that the runtime does not find the licensefile?
BR
Edwin
Edwin,
I am still using the demo version. I can purchase a license if required. Right now I am playing with different images and different PI's. My plan was to buy a license once I get Canbus working. This way I do not have keep moving the license when using a new image or PI.
I have to done the following:
#1 Disable codesyscontrol at boot up
#This was required because CanSocket does not want to load if codesyscontrol is first loaded
sudo update-rc.d codesyscontrol disable
reboot
#2 Load all required drivers and start CanSocket
modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=17:pd=20:pds32-0=10000000:pdu32-4=0x2002:force_release
modprobe spi-bcm2708
modprobe can
modprobe can-dev
modprobe can-raw
modprobe can-bcm
modprobe mcp251x
ip link set can0 up type can bitrate 250000
#3 Start codesyscontrol
service codesyscontrol start
#4 From windows download the codesys program with Canbus->Canopen Manager
#5 Start PLC from windows codesys
Hi,
no, you do not need to purchase a license, but please use 3.5.5.0 because then you have the same
version that I use and in my case I do not see the error in the log: license file missing - License File missing -> think fieldbus will not work
even not in Demo mode.
The limitation of the demo pi runtime is:
All fieldbus feature are running but the runtime quits after 2h of working in full mode.
So for sure you do not need to buy a license for our tests.
BR
Edwin
Edwin,
The error in the log: license file missing - License File missing only happens when I modified the /etc/CODESYSControl.cfg with the CanBus lines. If take out the CanBus in the codesys program and I comment out the lines below and restart the codesyscontrol service it does not have an error. See attached screenshot.
#/etc/CODESYSControl.cfg CanBus commented out
[ComponentManager]
Component.1=CmpOpenSSL
;Component.2=CmpCAACanL2
;Component.3=CmpCAASdoServer
;Component.4=CmpCAASdoClient
;Component.5=CmpSocketCanDrv
Hi,
I need to reproduce this with real CAN hardware, at the moment I have only a Pi
without PiCan. Give me a few day's to investigate it.
BR
Edwin
Edwin,
Thanks. Let me know if you need remote access to my PI.
Also if the creator of the pre-compiled modules would also compile the virtual driver, true hardware would not be required for testing. I did not have the time to set up a cross compiler to compile the modules myself. I will try to e-mail the creator if he would also include the virtual driver.
jzhvymetal
Hi jzhvymetal,
I've tested this now,
to be honest not with MCP2515 (because my hardware seems to be somehow broken)
I've used Peak CAN Dongle but this makes no difference both are based on socketcan.
How does it work:
You need to copy the rts_set_baud.sh to the /root/ directory and make it executeable by chmod +x rts_set_baud.sh
#!/bin/sh
CAN_NUM=$(echo $1 | sed 's,^can([0-9]).,\1,')
./pcan /dev/pcanusb$CAN_NUM $2
(In case of MCP2515 check if you need to modify it slightly)
For other users reading this post:
For using peak usb can or MCP2515 CAN interface it is needed to compile the kernel and enable CAN and the modules/interfaces which you want to use. This is the missing part - but we could not add this to the standard store image - because
there is a lot of effort to test it and the experience till now was that on high load you might loose CAN Messages.
BR
Edwin
rts_set_baud.zip [211 Bytes]
Hi jzhvymetal,
now additional for others and you the description how it works with MCP2515 PICan interface.
@jzhvymetal skip the parts with the kernel update.. you need only the scripts to set the baud and the start the runtime after loading the can modules.
http://skpang.co.uk/catalog/pican-canbu ... -1196.html
I have used the how to on that link:
http://www.raspberrypi.org/forums/viewt ... &start=550
Summerize:
Write following commands in terminal:
sudo rpi-update bfd37013c701f10c6df585346ee1d3d3bdf88b3b
#reboot
cd /tmp; wget http://lnxpps.de/rpie/rpi-can-3.12.22+.tar.bz2
cd /; sudo tar jxvf /tmp/rpi-can-3.12.22+.tar.bz2
sudo depmod -a
sudo reboot
sudo modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=25:pd=20:pds32-0=16000000:pdu32-4=0x2002:force_release
sudo modprobe mcp251x
sudo ip link set can0 up type can bitrate 250000
sudo ip -s -d link show can0
At this point CAN works now (under Linux Wheezy)
What is additional needed to run it in the CODESYS runtime:
add in
/etc/CODESYSControl.cfg
[ComponentManager]
Component.1=CmpOpenSSL
Component.2=CmpCAACanL2Component.3=CmpCAASdoServerComponent.4=CmpCAASdoClientComponent.5=CmpSocketCanDrv
then for testing purpose add a script in /home/pi
startplc.sh (this is needed for have the right start order.. 1. load modules .2 start plc)
#!/bin/sh
sudo /etc/init.d/codesyscontrol stop
sudo modprobe spi-config devices=bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=25:pd=20:pds32-0=16000000:pdu32-4=0x2002:force_release
sudo modprobe mcp251x
sudo ip link set can0 up type can bitrate 250000
sudo ip -s -d link show can0
sudo /etc/init.d/codesyscontrol start
this stops the runtime
load the modules
and starts the plc again
additional you need a script in the runtime directory (in our case /root)
cat /root/
rts_set_baud.sh
#!/bin/sh
BITRATE=
expr $2 \\* 1000ifconfig $1 down
echo ip link set $1 type can bitrate $BITRATE
ip link set $1 type can bitrate $BITRATE
ifconfig $1 up
Let's see if this work for you and others too
and let's see how stable the implementation is (according of losing messages etc)
BR
Edwin
rts_set_baudPican.zip [231 Bytes]
Edwin,
I am still having trouble with the CAN SPI model with codesys. I can get the can SPI working directly from the console and able to send message to my PeakCan usb adapter.
As soon as I start the codesyscontrol by typing the following "service codesyscontrol start" the Can adapter drops out. If I type ifconfig the can0 is no longer listed. Also if type dmesg I get the following output that repeats
[ 482.345440] mcp251x spi0.0: MCP251x didn't enter in conf mode after reset
It looks like when I run the codesyscontrol service it trys to reinitialize SPI causing the CAN apapter to drop out.
Also you no longer have to use the older Raspbian 3.10.22+ there is a new complied version of the drivers for the latest kernel Raspbian 3.12.28+ (http://lnxpps.de/rpie/)
Hi,
think at this point we should check online together...
Think you should send a pm to arrange this.
BR
Edwin
Edwin,
I got CAN Bus working. The problem was the GPIO pins for the interrupt for mcp251x (GPIO17 in my case) and for some reason GPIO04 need to be disabled in the Codesys program. Also every time you do a full download it will reinitialize the GPIO pins which causes the CAN SPI module to stop working. This does not happen if you disable all the GPIO pin in the Codesys program.
Edwin,
I have some good news to report. The modules for SPI and MCP251x are buggy in the tree. The good news is there are updates outside the main tree that fix the problems.
MCP2515 SPI CAN Uses the spi_async API directly for improved performance.
http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=commit;h=7d88d3d6142152d2edd42aefdf79058138b23e1d
spi-bcm2708 SPI master driver with DMA support for the Raspberry Pi
https://github.com/notro/spi-bcm2708
https://github.com/notro/spi-bcm2708/wiki
After compiling and updating the kernel and modules, CanBus has been going no stop for the 2 hour demo (Still have not purchased a license). I was able to have a 1ms cyclic with data changing on a remote I/O(OTB) every 5ms. This was done by having the output wired directly into an input on the remote I/O unit(OTB). See the attached screenshot
Attached is a procedure to cross compile all modules/kernel/canutils using Ubuntu. Also provided is the compiled modules for the current latest kernel.
Ubuntu Compile RPI CANBUS kernel v1.txt [5.1 KiB]
_modules_3.12.28+.zip [12.45 KiB]
Edwin,
I did a stress testing using the CanEcho program and USB PCAN adapter. Running the 1ms cyclic task for the CanEcho program and had PCANView sending every 2ms with CanBus set for 250kbps. The results show that every transmission was echoed by the PI with no drop outs for 8hours and still going. I just can not explain why the PI transmitted more message than the PCAN transmitted. Any case I am impressed by the results. This was done with a non-optimized PI without overclocking.