April-15th-2019, 06:38 PM
Hello,
I tried now for a couple of hours to combine the two containers
hilschernetpi/netpi-codesys-basis
and
hilschernetpi/netpi-netx-ethernet-lan/
It seems that the core part of the work should not be a big deal. But i struggle with a entrypoint.sh issue.
I use a windows machine to combine the two containers.
Always when I try to deploy the container to the netpi the following error is displayed by portainer
OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown
Up to now I tried:
1) Add the following line to the dockerfile: RUN chmod +x /entrypoint.sh
2) Add the following commands to the dockerfile: RUN dos2unix /entrypoint.sh && apt-get --purge remove -y dos2unix && rm -rf /var/lib/apt/lists/*
3) Change the encoding to ANSI
4) Use dos2unix directly on the windows machine
5) Comment the line #ENTRYPOINT ["/entrypoint.sh"]
In all of the 5 cases the same error message persists and comes up.
Could you please help/comment.
Best,
Andreas
April-15th-2019, 09:23 PM
I know such a problem very well and indeed your problem is the windows file system that cannot save the file “entrypoint.sh” file as being “Linux” executable.
So once you copied the original files from the repository onto your windows machine the executable property got lost.
Now back to the problem and how to solve it. First of all the command “chmod +x entrypoint.sh” is definitively the correct command to call. You said you tried it already but I have no explanation right now why it should not work.
What I basically can tell you is that I know at least three customer how combined these two containers already
successfully. So the root cause are not the containers themselves.
How about posting your Dockerfile...
I have another recommendation. Your container crashes for sure...but during container start you can specify a different entrypoint online. Use “/bin/bash” instead and use it in terminal and interactive mode. And then use the embedded console in portainer.io to jump into the container and use Linux commands as usual. Then go to your entrypoint.sh file and watch it if it is really not executable
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
April-16th-2019, 01:49 PM
Hello Andreas, I rechecked the codesys container once again. I see the latest update made 12 days ago in its tag list and it is not of type private. Or do I misunderstand your statement and your own repository was private?
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
April-16th-2019, 02:23 PM
(This post was last modified: April-16th-2019, 02:24 PM by Armin@netPI.)
Thank you for clarifying.
With CODESYS there is nothing else that needs to be done with the eth0 interface. Docker automatically maps this interface into any container you deploy. What you could additional try is to enable also WIFI of your netPI and try to get in touch with codesys runtime so that the eth0 interface is completely “free” to be used by codesys.
Unfortunately I have not made any experiences with codesys and Ethercat Master but with PROFINET only.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
April-16th-2019, 03:03 PM
Hello,
It seems that the EtherCAT driver cannot access the ethernet intercace eth0.
In the codesys log in /tmp/ the following line can be seen
DrvEtherCat No interfaces found
At the moment I have no idea what could be wrong.
Andreas
April-16th-2019, 03:10 PM
That sounds weired to me. Is there a specific IP address range or setup necessary. How about testing the very same configuration with an original RPi3?
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
April-17th-2019, 05:38 PM
(This post was last modified: April-17th-2019, 05:39 PM by Armin@netPI.)
Well if you read the readme of the Codesys container carefully it says using Field network communications such as Profinet or EtherCAT along with Codesys requires to start the container in “host” mode, else in “bridged” mode the container is getting a local IP address (typically 172.17.0.1...2...3) and subnet mask (255.255.0.0) by Docker and the master function can hence only be driven to this subnet (172.17.0.x) only which is not what you want. Therefore the host mode is needed letting the TCP/IP stack (and the IP setting) of the host system be shared with the container giving full access to eth0 then as if it is running on the host.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)