I have been excited to venture into the CODESYS world having seen it as an option for STW technic controllers. I have bought the Raspberry Pi license and have not used it yet as I am first trying the system on a Beaglebone Black Rev C. I finally got around to testing CODESYS V3 (3.5 SP12 Patch 4) on the current distro of Debian Stretch (Debian 9.4 2018-06-17 4GB SD IoT). Also tried Debian LXQT though find the desktop environment pointless. I have found 3 issues I have not been able to solve;
Our primary issue;
-1) - CAN bus locks up any CAN device or CAN network I wire to.
For initial setup, following Edwin's post from July 14, 2016, from a fresh IoT image, I installed the BoneRT kernel, didn't need to change CPU governor as it defaulted to performance, added cape_enable=bone_capemgr.enable_partno=BB-CAN1 to the uEnv.txt file, and flashed to eMMC.
Initial perceptions are that the process still works without any perceived issues.
From CODESYS, scanning the network didn't find the Beaglebone, though did find the NVidia Jetson TX2 we are testing. Manually inputting the IP address resolved the issue.
Installing the CODESYS package went without issue, and system info displayed expected results, along with license info when inputted.
CAN bus setup was identical to this video, https://www.youtube.com/watch?v=jkNB7CRpuW8&t=213s which was for CanOPEN (what we would like to use it for. We used an EDS file for a Trafag pressure transducer we have. We could not get any communication from the sensor. We previously tested the pressure transducer to confirm baud rate (500kbps) and node ID. We noticed the scan for devices within CanOPEN froze the CODESYS environment.
Hardware wise, we tried both the Waveshare RS485 and Can cape with jumpers set to UART1 for RX and TX (P9-24 and P9-26), and wiring directly a CAN transciever.
Though CanTX is mapped to the RX pin, and CanRX is mapped to the TX pin, we tried both orientations. We used an oscilloscope which can also decode CAN traffic, and was able to confirm the proper operation of the transducer.
We also tried a CAN J1939 joystick input device and set up CODESYS for the device which has a 64983 PGN with no luck. We also tried the whole process on two seperate brand new Beaglebone Black Rev C and used two different can transceivers and two different CAN capes. I believe hardware is likely not the issue. Canopen_Manager reports Running under Status. Does this confirm a properly set up Beaglebone? or simply the CODESYS runtime?
Does the new Debian Stretch which has the slots file disabled as is now controlled by uboot require any changes to the setup for CAN on the Beaglebone? Are there any setup differences when using a smart cape which utilizes the I2C bus for cape recognition, versus not using a cape and wiring a CAN transceiver directly?
Does any level of SSH debugging affect CODESYS when the runtime is running? Can I expect to be able to candump can1 while CODESYS is operational?
Does CAN Network # related to CAN0 = 0 and CAN1= 1 regardless of which CAN ports are enabled?
2) - Analog input pins do not seem to work;
Strike that, I did not set the value to Input for the analog pins on the parameters tab. Now That I have changed all of the parameters, only one of the AIN pins show an expected result (AIN0/P9_39).
3) - Boot time increased from about 14 seconds to about 2 minutes after the real-time kernel was loaded;
So far, I have only disabled Apache2 server to try to improve. Is the real-time kernel the cause of this? Is timing that much worse if not using the RT kernel?
Zitat:
Canopen_Manager reports Running under Status. Does this confirm a properly set up Beaglebone? or simply the CODESYS runtime?
This indicates that everthing is proberly set.
Is it possible to receive/send can messages by using the Linux shell: cansend can0... you should give this try.
Please check the plc logger in CODESYS for more information.
Zitat:
Does the new Debian Stretch which has the slots file disabled as is now controlled by uboot require any changes to the setup for CAN on the Beaglebone? Are there any setup differences when using a smart cape which utilizes the I2C bus for cape recognition, versus not using a cape and wiring a CAN transceiver directly?
If you manage to use SocketCAN on Linux this should work with the CODESYS runtime too. ( guess you Need to modify rts_set_baud.sh)
according the Analog Inputs you need to set the Parameter to enable them.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did not load the real-time kernel. I feel it is safe to say that the current real-time kernel breaks the firmware file "/lib/firmware/BB-CAN1-00A0.dtbo" which fails to change the pin mode for pins 96 and 97 from UART1 RX and UART1 TX to Mode 2 for DCAN1 RX and DCAN1TX. This can be seen by checking current pin mux status with;
which should show (if everything is working correctly for CAN);
...
pin 96 (44e10980.0): 481d0000.can (GPIO UNCLAIMED) function pinmux_dcan1_pins group pinmux_dcan1_pins
pin 97 (44e10984.0): 481d0000.can (GPIO UNCLAIMED) function pinmux_dcan1_pins group pinmux_dcan1_pins
I can not get this to happen when loading the real-time kernel with "./update_kernel.sh --bone-rt-kernel --stable" no matter what I tried. I will have to stick with the non-realtime kernel for now since boot time is much faster and CAN works.
cape_enable=bone_capemgr.enable_partno=BB-CAN1 is not working anymore because as far as I understand it, this is no ONLY handled by Uboot which uses overlays.
Regarding the Analog input pins:
I was able to get all analog input pins active, though all but AIN0 act like they update about once per minute. I have the output of a potentiometer going into all the AIN pins and only AIN0 updates as expected. Do I have to poll one pin individually per loop cycle? It would be hard to describe without a screen recorder. I may try recording with my cell phone and uploading a short video.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been excited to venture into the CODESYS world having seen it as an option for STW technic controllers. I have bought the Raspberry Pi license and have not used it yet as I am first trying the system on a Beaglebone Black Rev C. I finally got around to testing CODESYS V3 (3.5 SP12 Patch 4) on the current distro of Debian Stretch (Debian 9.4 2018-06-17 4GB SD IoT). Also tried Debian LXQT though find the desktop environment pointless. I have found 3 issues I have not been able to solve;
Our primary issue;
-1) - CAN bus locks up any CAN device or CAN network I wire to.
For initial setup, following Edwin's post from July 14, 2016, from a fresh IoT image, I installed the BoneRT kernel, didn't need to change CPU governor as it defaulted to performance, added cape_enable=bone_capemgr.enable_partno=BB-CAN1 to the uEnv.txt file, and flashed to eMMC.
Initial perceptions are that the process still works without any perceived issues.
From CODESYS, scanning the network didn't find the Beaglebone, though did find the NVidia Jetson TX2 we are testing. Manually inputting the IP address resolved the issue.
Installing the CODESYS package went without issue, and system info displayed expected results, along with license info when inputted.
CAN bus setup was identical to this video, https://www.youtube.com/watch?v=jkNB7CRpuW8&t=213s which was for CanOPEN (what we would like to use it for. We used an EDS file for a Trafag pressure transducer we have. We could not get any communication from the sensor. We previously tested the pressure transducer to confirm baud rate (500kbps) and node ID. We noticed the scan for devices within CanOPEN froze the CODESYS environment.
Hardware wise, we tried both the Waveshare RS485 and Can cape with jumpers set to UART1 for RX and TX (P9-24 and P9-26), and wiring directly a CAN transciever.
Though CanTX is mapped to the RX pin, and CanRX is mapped to the TX pin, we tried both orientations. We used an oscilloscope which can also decode CAN traffic, and was able to confirm the proper operation of the transducer.
We also tried a CAN J1939 joystick input device and set up CODESYS for the device which has a 64983 PGN with no luck. We also tried the whole process on two seperate brand new Beaglebone Black Rev C and used two different can transceivers and two different CAN capes. I believe hardware is likely not the issue. Canopen_Manager reports Running under Status. Does this confirm a properly set up Beaglebone? or simply the CODESYS runtime?
Does the new Debian Stretch which has the slots file disabled as is now controlled by uboot require any changes to the setup for CAN on the Beaglebone? Are there any setup differences when using a smart cape which utilizes the I2C bus for cape recognition, versus not using a cape and wiring a CAN transceiver directly?
Does any level of SSH debugging affect CODESYS when the runtime is running? Can I expect to be able to candump can1 while CODESYS is operational?
Does CAN Network # related to CAN0 = 0 and CAN1= 1 regardless of which CAN ports are enabled?
2) - Analog input pins do not seem to work;
Strike that, I did not set the value to Input for the analog pins on the parameters tab. Now That I have changed all of the parameters, only one of the AIN pins show an expected result (AIN0/P9_39).
3) - Boot time increased from about 14 seconds to about 2 minutes after the real-time kernel was loaded;
So far, I have only disabled Apache2 server to try to improve. Is the real-time kernel the cause of this? Is timing that much worse if not using the RT kernel?
Thank You,
-Phillip Rhyner
BBBCan.project [264.04 KiB]
Hi,
This indicates that everthing is proberly set.
Is it possible to receive/send can messages by using the Linux shell: cansend can0... you should give this try.
Please check the plc logger in CODESYS for more information.
If you manage to use SocketCAN on Linux this should work with the CODESYS runtime too. ( guess you Need to modify rts_set_baud.sh)
according the Analog Inputs you need to set the Parameter to enable them.
BR
Edwin
Edwin,
Thank you for your prompt response. I have an update on two of the issues I have found.
CAN not working issue:
I loaded a fresh image of the latest Debian (Stretch V9.4) and simply added the following line to /boot/uEnv.txt
uboot_overlay_addr4=/lib/firmware/BB-CAN1-00A0.dtbo
I did not load the real-time kernel. I feel it is safe to say that the current real-time kernel breaks the firmware file "/lib/firmware/BB-CAN1-00A0.dtbo" which fails to change the pin mode for pins 96 and 97 from UART1 RX and UART1 TX to Mode 2 for DCAN1 RX and DCAN1TX. This can be seen by checking current pin mux status with;
cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
which should show (if everything is working correctly for CAN);
...
pin 96 (44e10980.0): 481d0000.can (GPIO UNCLAIMED) function pinmux_dcan1_pins group pinmux_dcan1_pins
pin 97 (44e10984.0): 481d0000.can (GPIO UNCLAIMED) function pinmux_dcan1_pins group pinmux_dcan1_pins
I can not get this to happen when loading the real-time kernel with "./update_kernel.sh --bone-rt-kernel --stable" no matter what I tried. I will have to stick with the non-realtime kernel for now since boot time is much faster and CAN works.
cape_enable=bone_capemgr.enable_partno=BB-CAN1 is not working anymore because as far as I understand it, this is no ONLY handled by Uboot which uses overlays.
Regarding the Analog input pins:
I was able to get all analog input pins active, though all but AIN0 act like they update about once per minute. I have the output of a potentiometer going into all the AIN pins and only AIN0 updates as expected. Do I have to poll one pin individually per loop cycle? It would be hard to describe without a screen recorder. I may try recording with my cell phone and uploading a short video.