CODESYS ControlMade for, the Raspberry Pi 3B Architecture based industrial suited Open Edge Connectivity Ecosystem Secured netPI DockernetPI features a restricted Docker protecting the system software's integrity by maximum. The restrictions are. privileged mode is not automatically adding all host devices /dev/ to a container. volume bind mounts to rootfs is not supported. the devices /dev, /dev/mem, /dev/sd., /dev/dm., /dev/mapper, /dev/mmcblk.
![]() ![]() ![]()
This example shows how to use the serial port. Therefore the communication of two ports with each other is implemented. The first one writes a string of characters, which is read by the second one.
cannot be added to a containerContainer featuresThe image provided hereunder deploys a container with a basic setup of Linux tools, utilities and default user needed for a flawless installation of the CODESYS Control for Raspberry Pi (SL and MC SL) packages with the Windows® based (free).Base of this image builds with enabled and created default user 'pi'(sudo). This setup is equivalent to a stripped down Raspbian OS with least capabilities.Once the container is deployed it needs an upgrade with the following packages you can download from the CODESYS store. or. (needed since version V3.5.15.x)Container licensingIf not licensed the 'CODESYS Control for Raspberry Pi' SoftPLC runtime operates 1 hour and then stops. A is needed to make it run an unlimited time.A license purchase follows an email with a ticket number (e.g A78HY-TBVMD-8SVC7-P8BHX-4LED6) granting you the license.
The Tools-License Manager in the CODESYS Development System (internet needed) transforms the ticket number in a deployed license. The ticket number can be used only one time and gets invalid during the licensing procedure.It is possible to deploy a license to either a CODESYS Runtime Key (USB dongle) or to a software container.IMPORTANT NOTE: A software container needs special care since the license is stored on the device itself in the Docker container. If this container is lost or destroyed by any reason or is deleted your license copy is gone forever!!! This is why a license backup is obligatory in this case.To backup the license file '3SLicenseInfo.tar' follow this.To restore the license file '3SLicenseInfo.tar' follow this. Container setup Host networkThe container needs to run in host network mode.Using this mode makes port mapping unnecessary since all the used container ports (like 22) are exposed to the host automatically. Privileged modeThe privileged mode option needs to be activated to lift the standard Docker enforced container limitations. With this setting the container and the applications inside are the getting (almost) all capabilities as if running on the Host directly Host devicesThe CODESYS runtime perfoms a license versus serial number check across the device VideoCore GPU when started.
To grant access to the GPU chip the /dev/vcio host device is mandatory to add to the container.In case a CODESYS Runtime Key Dongle is used for licensing the host device /dev/hidraw0 needs to be added to the container. Additional Ethernet LAN Interface on netPI RTE 3 (optional)The container configures the two RJ45 Industrial Ethernet ports (RTE) as standard LAN interface (single MAC address, but switched) named cifx0 automatically if the following devices found added to the container. host device /dev/spidev0.0 granting access to the network controller netX driving the RTE ports. host device /dev/net/tun granting access to network interface registering logicSince the container runs in 'Host network' mode the container host treats the cifx0 as a standard LAN interface. This is why the cifx0 IP settings are configured in the netPI's network/LAN settings dialog (like 'eth0' interface).
Any change on the IP settings needs a container restart to accept the new IP parameters.netPI RTE 3's Industrial network controller netX was designed to support all kind of Industrial Networks as device in the first place. Its performance is high when exchanging IO data from and to a master PLC and any Host application via IO buffers periodically. The controller was not designed to support high performance message oriented exchange of data as used with Ethernet communications. This is why the provided cifx0 interface is a low to mid-range performer but is still a good compromise to add another Ethernet interface to netPI RTE 3 on demand.Measurements have shown that around 700 to 800MByte/s throughput can be reached across cifx0 whereas with netPI's primary Ethernet port eth0 10MByte/s can be reached.
Reasons are:. 25MHz SPI clock frequency between netX and Raspberry Pi CPU only. User space driver instead of a kernel driver. 8 messages deep message receive queue only for incoming Ethernet frames.
SPI handshake protocol with additional overhead between netX and Raspberry Pi during message based communicationsThe cifx0 LAN interface will drop Ethernet frames in case its message queue is being overun at high LAN network traffic. The TCP/IP network protocol embeds a recovery procedure for packet loss due to retransmissions. This is why you usually do not recognize a problem when this happens. Single frame communications using non TCP/IP based traffic like the ping command may recognize lost frames.The cifx0 LAN interface DOES NOT support Ethernet package reception of type multicast. Container deploymentSTEP 1. Open netPI's website in your browser (https).STEP 2. Click the Docker tile to open the Docker management user interface.STEP 3.
Enter the following parameters under Containers + Add Container ParameterValueRemarkImagehilschernetpi/netpi-codesys-basisNetwork NetworkhostRestart policyalwaysRuntime Devices +add deviceHost path /dev/vcio - Container path /dev/vcioRuntime Devices +add deviceHost path /dev/hidraw0 - Container path /dev/hidraw0for CODESYS Runtime Key DongleRuntime Devices +add deviceHost path /dev/spidev0.0 - Container path /dev/spidev0.0for cifx0 LANRuntime Devices +add deviceHost path /dev/net/tun - Container path /dev/net/tunfor cifx0 LANRuntime Privileged modeOnSTEP 4. Press the button Actions Start/Deploy containerPulling the image may take a while (5-10mins). Sometimes it may take too long and a time out is indicated. In this case repeat STEP 4. Container accessA fresh container can immediately be upgraded with your downloaded packages from the CODESYS store. Here is how to proceedSTEP 1: Upgrade your CODESYS development system first with support for Raspberry Pi/Linux compatible platforms using the function Tools-Package Manager-Install.
Choose your packages 'CODESYS Control for Raspberry Pi 3.5.xx.xx.package' and 'CODESYS Edge Gateway for Linux 3.5.x.x.package' and click Install.STEP 2: Restart the development system to activate the installed packages extending the top menu bar Tools by two new functions.STEP 3: Use the new function Tools-Update Raspberry Pi to deploy your 'CODESYS Control for Raspberry Pi' package to the container. Enter the user pi and the password raspberry as Login credentials. Enter your netPI's IP address in Select target-IP address, choose the version under Package you want to install and press Install. The installation may take up to 1 minute. Choose Standard or Multicore runtime mode during installation.STEP 4: Use the new function Tools-Update Edge Gateway to deploy your 'CODESYS Edge Gateway for Linux' package to the container. Enter the user pi and the password raspberry as Login credentials.
Enter your netPI's IP address in Select target-IP address, choose the version V3.5.x.x.(armhf) under Package you want to install and press Install. The installation may take up to 1 minute.
The container is now well prepared and ready to receive a project.STEP 5: Create a CODESYS new project. Choose Standard Project and as Device 'CODESYS Control for Raspberry Pi xx' and then ok. After project creation double click the topmost Device(CODESYS Control for Raspberry Pi) in the project tree.STEP 6: Setup a communication from the CODESYS development system to the container Edge Gateway. Use the function Gateway-Add New Gateway in the dialog Device. As gateway IP-address use the netPI IP address at port 1217 and click ok. Use the option Device-Scan Network.
Option and click the found device found. NTB827EBEA02D0 0000.0539 and ok. Container testThe container has been successfully tested against the in the version V3.5.15.10 and the and both in the version V3.5.15.10 Container cifx0 Ethernet frame throughput (on netPI RTE 3)netPI RTE 3's Industrial network controller netX was designed to support all kind of Industrial Networks as device in the first place.
Its performance is high when exchanging IO data from and to a master PLC and any Host application via IO buffers periodically. The controller was not designed to support high performance message oriented exchange of data as used with Ethernet communications. This is why the provided cifx0 interface is a low to mid-range performer. But is still a good compromise to add another Ethernet interface to netPI optionally.Measurements have shown that around 1MByte/s throughput can be reached across cifx0 whereas with netPI's primary Ethernet port eth0 10MByte/s can be reached in the middle. The reasons for this is the following:.
25MHz SPI clock frequency between netX and Raspberry Pi CPU only. User space driver instead of a kernel driver, but enabling its use in a container. 8 messages deep message receive queue only for incoming Ethernet frames.
SPI handshake protocol with additional overhead between netX and Raspberry Pi during message based communicationscifx0 will drop Ethernet frames in case its message queue is being overun at high traffic. A TCP/IP based protocol embeds a recovery from this state when frames are lost.
This is why you usually do not recognize a problem when this happens. Using single frame communications with no additional protocol for data repetition like the ping command could result in lost frames indeed. Container YoutubeHINT: The software version shown in the video may differ from yours and screens/options/windows may look different meanwhile. The video also doesn't show the mapping of the /dev/vcio and /dev/spidev0.0 host devices when the container is deplyed and no installation of the Edge Gateway package.Container automated buildThe project complies with the scripting based method to build the image output file.
Using this method is a precondition for an web based build process on DockerHub platform.DockerHub web platform is x86 CPU based, but an ARM CPU coded output file is needed for Raspberry systems. This is why the Dockerfile includes the steps. LicenseView the license information for the software in the project.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.Hilscher Gesellschaft fuer Systemautomation mbH.
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2023
Categories |