Hilscher Community Forum
EtherCAT Master: any options? - Printable Version

+- Hilscher Community Forum (https://forum.hilscher.com)
+-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html)
+--- Forum: Software (https://forum.hilscher.com/forum-5.html)
+--- Thread: EtherCAT Master: any options? (/thread-219.html)

Pages: 1 2 3 4 5


RE: Answer - andreash - April-15th-2019

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


RE: EtherCAT Master: any options? - Armin@netPI - April-15th-2019

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


RE: EtherCAT Master: any options? - andreash - April-16th-2019

(April-15th-2019, 09:23 PM)Armin@netPI Wrote: 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

Hello Armin,

thank you for your answer. At the moment I cant even connect to the bash via the portainer command line utility because the conainter image which is a copy of hilschernetpi/netpi-codesys-basis restarts when it tries to start (At container creation I set as override entrypoint /bin/bash). I think that this permission issue is the problem.

Using Ubuntu cloning hilschernetpi/netpi-codesys-basis to my own repository works. Another problem was that the container was never updated from dockerhub, when the repository was switched to private (obviously). Portainer did not complain and used the available local image all the time without notification, hence the changes made to the dockerhub repository were not deployed to the device. To circumvent that make sure that you delete all local copies of the images and that you set yout docker hub repository to public.

I do not doubt that others did the merge successfully. Im trying further and will report here

Best,
Andreas


RE: EtherCAT Master: any options? - Armin@netPI - April-16th-2019

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?


RE: EtherCAT Master: any options? - andreash - April-16th-2019

Hello Armin,

Sorry this was a misunderstanding. I referred to my repository fokkersim/netpi-codesys-netx-nodered which is now not private anymore.
  • At the moment I can connect to the NetPI via cifx0 (RTE port) and ssh at port 22
  • I can then install the CodesysControl runtime for SC devices and program the soft PLC
Still I cannot get the EtherCAT Master in codesys to work with the eth0 interface. Is there maybe the need to make eth0 available to the container?
Is any special reconfiguration needed for eth0 to be operated as EtherCAT master. I noticed that the mac address which is provided by ifconfig for eth0
is not the same as printed on the sticker on the device housing.


By the way I still connect to the Edge Gateway Manager via eth0.

Best,
Andreas


RE: EtherCAT Master: any options? - Armin@netPI - April-16th-2019

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.


RE: EtherCAT Master: any options? - andreash - April-16th-2019

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


RE: EtherCAT Master: any options? - Armin@netPI - April-16th-2019

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?


RE: EtherCAT Master: any options? - andreash - April-17th-2019

(April-16th-2019, 03:10 PM)Armin@netPI Wrote: 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?

Hello Armin,

now the EtherCAT master works on eth0 if and only if the container with codesys and netx (fokkersim/netpi-codesys-netx-nodered) is deployed in host mode on the NetPi. If it is used in bridge mode the EtherCAT master does not work. Do you have any idea why this is the case? I suspect some Ethernet Packages not being forwarded properly in the docker net in bridge mode.

Codesys management, Edge Gateway Manager and NodeRed is accessed via cifx0. The remaining task is now to set up a communication between the codesys netx container and NodeRed.

Best,
Andreas


RE: EtherCAT Master: any options? - Armin@netPI - April-17th-2019

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.