Hi, i’m a new user of plcnext technology, and i’m stucked with a tough problem (for me…). I’m trying to deploy pyzmq in python on AXF2152. Since there is no gcc on the target, legacy ‘pip3 install pyzmq’ doesn’t work, since there is no pre-built pyzmq for arm ( and the preferred method for pyzmq is to link against the local linux shared library) To get around this problem, i tried to deploy python with ipkg (with the method explained in Automation Maker #004: Python, PIP and PLCnext Control, but on the source repository there is no build of this package, so it doesn’t work. I tried to use python crossenv, but you have to recompile the python sources. It is possible since it’s possible to get the compilation options options in the already shipped python (3.8.2), but it’s a very tedious task. I don’t want to do that each time a new firmware is delivered… More, we plan to deploy the soft on multiple PLCNext platforms (3152, 4072, etc ) for multiple projects, so I want to skip this task for each platform… Another way i explored is to use buildroot which does the job, but the toolchain provided is done by Yocto and is more or less incompatible with buildroot… I didn’t finish to investigate this way of doing things, but maybe it should be more simple to do that with yocto project. Last way was to deploy during the time of python deployment to deploy a gcc on the target. Since only a X86 version is provided in the SDK, i tried to deploy an alternate version, but at least, binaries seems tto be incompatible so this way was a dead end… So I have multiple questions : - is anybody is doing more or less same things (maybe with another python package) and achieved to deploy it on AXF2152 ? - is it possible to have a pypi server with prebuilt binaries for PLCNextTargets ? Maybe this could be maintained by PhoenixContact Teams (like this project : piwheels , but on a restricted set of python packages useful for the community ) OR could we have a cookbook (maybe a process) to deploy python packages, with parts of the yocto project shipped? Thank you for the help ! JM
Hey JM, you are right, we have room for improvement when it comes down using not “pure” Python packages as the gcc is not part of the PLC. Even if, it would take for larger packages quite a lot time to compile them for the target. However, we have this point on our list and are searching for a good way. The tricky point is to keep the small footprint as we consider PLCnext Control still as an embedded device. Maybe it could be a way to offer a container with all necessary dependencies to compile those packages. Coming back to your question fo the repository. Even if I would love to have such a “PLCnext Repo” it is unlikely that we are able to offer such in the next time. A college from Chine (thx. to Yantao Song) crosscompiled the zmq package in the past. If you like Ican share it with you. Cheers, Frank
Hi Franck, Thanks for you answer. For the cross compilation of zmq (the shared object ), I could achieved it without problems with the compilers provided. It works in our runtime implementation without problems ( more exactly a colleague of mine did it with some questions on PLCNext community forum). The real problem is more the automatic generation of the pyzmq package which needs to choose very late how it will be linked with systems libraries ( if it finds no system libraries , it compiles itself the whole library). In fact it only links the so for python interface, but for that requires gcc. I will see if it possible to fork this python package to adapt the generation to the particularities of the embedded platforms, but without the complete cross compilation project it will be quite complicated. Maybe it will be a good thing to provide a space where community members having achieved this port could share their works easily with others people. ( particular project/group on the plcnext github for example ) I’ll keep you in touch if there are some success in my work ! thx
Hi Jmery, thankfs for your feedback and sharing your results with the community. The main problem is that the gcc requires too much memory on the internal SD card, therefore it is not part of the Firmware. We are thinking about providing a build environment as a container, which might be a good alternative. But that will still take a little time… In additional we are evaluating additional ways to share the most common packages, but also here it is a bit too early to go into the details. I like your idea with a common Python Repository in our GitHub Channel, I’ll discuss this with the team. Thx, Frank