Activity for sumkrnboy
-
sumkrnboy modified a comment on discussion Runtime 🇬🇧
The Linux ARM64 runtime doesn't work with the latest Raspberry Pi OS 64-bit image. pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux pi@raspberrypi:~ $ sudo dpkg -i codesyscontrol_linuxarm64_4.6.0.0_arm64.deb dpkg: error processing archive codesyscontrol_linuxarm64_4.6.0.0_arm64.deb (--install): package architecture (arm64) does not match system (armhf) Errors were encountered while processing: codesyscontrol_linuxarm64_4.6.0...
-
The Linux ARM64 doesn't work with the latest Raspberry Pi OS 64-bit image. pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux pi@raspberrypi:~ $ sudo dpkg -i codesyscontrol_linuxarm64_4.6.0.0_arm64.deb dpkg: error processing archive codesyscontrol_linuxarm64_4.6.0.0_arm64.deb (--install): package architecture (arm64) does not match system (armhf) Errors were encountered while processing: codesyscontrol_linuxarm64_4.6.0.0_arm64...
-
Download the file and overwrite the following file: /opt/codesys/scripts/init-functions Restart the CODESYS Control service: sudo service codesyscontrol restart After 30 seconds or so, check the status of the service to see that it is still running: sudo service codesyscontrol status
-
That fixed it. When can we expect an official fixed release?
-
With a fresh install of the latest Raspberry Pi OS image, https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-11-08/2021-10-30-raspios-bullseye-armhf-lite.zip it will work fine and run, however, after running the previously mentioned update and upgrade commands, it it fail to load after restart. This behavior was observed in both the Raspberry Pi 3B as well as 4B (4GB).
-
This was a fresh install. I performed the following: sudo apt-get update sudo apt-get upgrade After the above commands, the runtime terminates.
-
On the latest Raspberry Pi OS 32-bit image with updates performed and kernel as shown below, CODESYS Control for Raspberry PI runtime exits after about 30 seconds. Linux raspberrypi 5.10.92-v7l+ #1514 SMP Mon Jan 17 17:38:03 GMT 2022 armv7l ● codesyscontrol.service - LSB: Prepares and starts codesyscontrol Loaded: loaded (/etc/init.d/codesyscontrol; generated) Active: active (exited) since Fri 2022-01-21 12:01:11 PST; 31s ago Docs: man:systemd-sysv-generator(8) Process: 5053 ExecStart=/etc/init.d/codesyscontrol...
-
I have tried both methods with dual key (one in PLC, one in IDE) with same firm and product codes. That one fails. The other one with creating the boot application with the dongle plugged into the IDE also fails.
-
When can we expect a fix?
-
The product code is still 5555.
-
The product code is still 5555.
-
I have attached screenshots of the process. 1) The controller gets connected to the IDE. 2) Under license manager, it connects to the dongle of the PLC. 3) The product code (5555) under 'CODESYS Runtime Protection' is copied to the encryption screen as pictured. 4) There are no other PLCs connected to the network and I can go online if I deselect all of the encryption options. Otherwise, I get the error message. I have already tried this is another IDE connected to the same network with the same...
-
I already know the product code. The problem is that when this is connected to the PLC and I go connect to it in the IDE, it won't download after setting the matching product code.
-
I have the CODESYS issued key with firm code 101599 and the unique product code connected to the PLC. On the IDE side, when connection is established with the PLC and the same product code is entered, it fails to download the program with the same error message. I am assuming that the security key each has a unique product code that is laser marked on the dongle.
-
I have the CODESYS issued key with firm code 101599 and the unique product code connected to the PLC. On the IDE side, when connection is established with the PLC and the correct product key is entered, it fails to download the program with the same error message. I am assuming that the security key each has a unique product code that is laser marked on the dongle.
-
I have tried it with the CODESYS issued key with firm code 101599, but it does not work. Also, the article in the link above is contradicting what you are saying. Is the article wrong? (Under "2. Encryption with license management")
-
This is if I use CODESYS' dongle with firm code 101599, but we have our own FSB and firm code/product code. It is not allowing the process to go through. It looks like it may be a bug.
-
This is if I use CODESYS' dongle with 101599, but we have our own FSB and firm code/product code. It is not allowing the process to go through. It looks like it may be a bug.
-
On the Simple Encryption section, it shows the firm code of 101599 with the required product code input field. This is for the security dongle by CODESYS. However, the previous screenshot show that both the firm code and product code can be entered. The article states the following, "A new feature, soon to be released, is encryption with license management which allows for much greater flexibility. For example, the controller application manufacturer can create and manage licenses himself. He uses...
-
I am trying to encrypt the boot application, but it is not taking the firm code and product code of our dongles. I have tried following the article listed below, but I am getting the following message: "The en-/decryption of the sequence failed, Error 202." https://www.wibu.com/magazine/keynote-articles/article/detail/codesys-application-protection-made-easy.html How is this implemented?
-
I had already uninstalled that particular package, however, the problem persists.
-
No, it doesn't work. I still get the same error message.
-
If I try to reinstall the same package/version, I get the attached error message. If I uninstall the package and try to reinstall either the previous version or the new package, I get the same message from earlier. I have noticed that on another computer, if I don't have any other packages installed, the update completes successfully, however, it seems that there may be a compatibility issue with the other installed packages.
-
I get the same error message.
-
3.5.16.10
-
I'm getting an error message when trying to update the plugin from the Package Manager.
-
https://downloads.raspberrypi.org/raspios_armhf/images/
-
This just affects the Raspberry Pi 4B at the moment, I have tried the new Raspberry Pi OS image and I ran into the same issue. If I revert to the older kernel in this build, via the method described in the link below, the runtime software runs without issue. https://forge.codesys.com/forge/talk/Runtime/thread/4d43247a3a/#9bcd
-
This just affects the Raspberry Pi 4B at the moment, I have tried the new Raspberry Pi OS image and I run into the same issue. If I revert to the older kernel in this build, via method described in the link below, the software runs without issue again. https://forge.codesys.com/forge/talk/Runtime/thread/4d43247a3a/#9bcd
-
It should be noted that the official Raspberry Pi OS release is now at kernel 5.4 (Release date: 2020-08-20). https://www.raspberrypi.org/downloads/raspberry-pi-os/ The older version does not seem to be available now.
-
The last kernel version that runs the runtime from the list of commits below is 4.19.118. https://github.com/Hexxeh/rpi-firmware/commits/master If you have devices already provisioned and/or deployed out in the field, you can run the following command to revert to the last working revision: sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2
-
This issue still persists in version 3.5.16.10 as well.
-
pi@raspberrypi:~ $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 270.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 270.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU...
-
Edwin, I have the latest version installed from the same link. If I install the runtime, it will work. If I execute the following, then the kernel gets updated and the runtime will not run anymore. sudo apt-get upgrade -y When I look at the logs, it seems that the licensing parameters need to be updated as it thinks that the newly updated system is no longer a Raspberry Pi. ooops... this runtime was built for RASPBERRYPI (-8, 0x00000BB8, 0xFFFFFFFB) This is after updating: Linux raspberrypi 5.4.51-v7l+...
-
Edwin, Predictable network interface names is already disabled. On the Raspberry Pi 4B, this is my output: pi@raspberrypi:/var/opt/codesys $ sudo /opt/codesys/bin/codesyscontrol.bin -d /etc/CODESYSControl.cfg ********* CoDeSysControl DEMO VERSION - runs 2 hours********* PlcStart[206]: using /etc/CODESYSControl.cfg as config file machine: armv7l timer resolution: 1nsec Linux version 5.4.51-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1326 SMP Fri Jul 17 10:51:18...
-
Today, I've updated the Raspberry Pi OS with the following commands: sudo apt-get update -y sudo apt-get upgrade -y sudo apt-get dist-upgrade -y The CODESYS runtime exits within seconds. I have tried the same on another build with similar results.
-
I cannot update the plugin nor install it from the download. I am getting the following message:
-
I cannot update the plugin nor install it from the download. I am getting the following message:
-
I cannot update the plugin nor install it from the download. I am getting the following message:
-
I cannot update the plugin nor install it from the download. I am getting the following message:
-
I cannot update the plugin nor install it from the download. I am getting the following message:
-
Perhaps, it is time to revisit the 64-bit build of CODESYS due to the Raspberry Pi Foundation's public beta version of their Raspberry Pi OS 64-bit. Also, with the release of their new 8GB memory version of the Raspberry Pi 4B, running a 64-bit operating systems will become the standard.
-
Will there be a resolution for this issue? I have the same issue with version FW:16 as well on CODESYS V3.5 SP16.
-
It looks like GPIO 4 is used for 1-Wire, but what about 5 and 6? https://forge.codesys.com/forge/talk/Deutsch/thread/e9a3f4f78b
-
Version 3.5.15.40 of the PFC100 runtime installs and operates fine, but upon reboot of the controller, it seems to crash. I have tried this on two different PFC100 controllers with the same result.
-
On the latest release (2020-02-13) of Raspbian Lite as of this post, GPIO 4, 5 and 6 are always switched on without any actual inputs to the pins. The outputs on these pins are always high. The runtime build is 3.5.15.40. Are there other settings that need to be adjusted?
-
On the latest release (2020-02-13) of Raspbian Lite as of this post, GPIO 4, 5 and 6 are always switched on without any actual inputs to the pins. The outputs on these pins are always high. The runtime build is 3.5.15.40. Are there other settings that need to be adjusted?