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). I have Digital input and output pins working fine, but the 6 analog input pins in GPIOs P9/P8 always shows 0. I have the pins %IW18 - %IW24 mapped to application UINT variable and do not display any value. I will try to post the program I am currently working with.
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?