Hi guys, thank you to Martin Boers for hosting a Q&A; and answering all the questions that we could pose. If you missed it, I posted the link below. As someone that asked quite a few questions (and got quite a few answers!) I wanted to post a few follow-ups and thoughts. First, a question was posed about doing deep learning on the controller. There is a PLC that does this today - Omron’s NX/NY series AI controller. It is quite a beast and has a price tag to match! Furthermore, I don’t see any reason why someone couldn’t do this on PLCnext using PyTorch or TensorFlow in the Linux domain - performance would be slower than a dedicated AI machine but it should be possible on the higher end hardware and with an optimized neural network. Now a word on open source - thank you for providing a detailed breakdown of the components of PLCnext and the source status of each. One additional shout-out - my understanding is that Phoenix does support the open source community through the Open Source Automation Development Lab (OSADL) which is one of key players behind RT_Preempt. So thank you for that! While the developers of PLCnext are doing a great job of communicating the technical underpinnings of the software and the strengths and limitations of the quasi-open-source model, I fear that some of this gets lost in translation when passed through Phoenix’s product management, marketing team, regional offices, and local sales team. So please do your best to make sure everyone has clear understanding of what PLCnext is and is not! One note on the PLCnext runtime. On many projects that bundle the Linux kernel and other GPL works, I see requirements to distribute the full and complete source code for any derivative work. I am not a copyright or a copyleft expert - however, is this something that Phoenix could clarify? Furthermore, if I sell machines that embed PLCnext controls and my custom code, does this apply to my works as well? On hardware support. Thank you for clarifying the supported hardware platforms - let me add to the request for more options here. Being able to run a GPU for machine vision, or an PPC integrated form factor, or custom hardware interfaces (motion control, camera link) would be major advantage to the versatility of the platform. I don’t know what the best path to make that happen would be, but with a real-time Linux core, I would imagine there are a few options. The more relevant question that I meant to ask was actually about hardware peripherals. Can I retrofit existing systems just by dropping in a PLCnext controller? What kind of protocols and devices are supported? What manufacturers is Phoenix working with to provide a full ecosystem of supported hardware? (Hint hint: EtherCAT) Again, thank you for your time and willingness to discuss these issues out in the open. I think many would agree with me if I claimed that the ‘old ways’ of doing things in the automation world are hopelessly antiquated, and PLCnext - properly managed - might represent a way forward.
Hi Scott, thanks first of all to your open and valuable feedback, also on behalf of Martin! Also we believe that we’ve to go new ways, not only in technology also in terms of communication and your feedback encourage us to go further down this road. Well, coming now back to the technical stuff! Yeah, the open source topic is for some difficult to understand, but we’re working internal and external for the proper understanding.
Of course is the plattform open to use open source software, but at least the PLCnext runtime is not open source and also no derivative work.
Our development workflow content a licence clearance and even when we (of course) are also using some open source packages we’re not using any strict copyleft licences (like GPL or LGPL) on any parts of the runtime.
This not only important for us, but as well for our and your customers. As you sad, if our runtime would include such licences there would be anytime the risk that the whole application have to be published.
Of course, this could stil be the case if your application would use a package with strict copy left licence. However, all kernel sources (which are GPL) with all changes we’ve made are available on request. Machine learning is definitely a topic as well as the usage of a GPU is interested. Especially the AXC F 3152 is due to it’s powerful x86 architecture a good choice and we’ll come up also with some other interesting hardware solutions for that.
So, stay tunedThe Python3 interpreter is part of every PLCnext device, but unfortunately not yet the numpy package, but you can use deploy it (must be crosscompiled for the ARM targets) and than, yeah ready to go with most of the named ML libs. We’ve many customers who are indeed using the PLCnext Controls for retrofit and gateway solutions as it is typical more flexible than the other available stuff.
On the peripheral and protocol side we’ll come up with more left side extensions and of course EtherCat is a topic for us. So, thank you once again and I hope that we can welcome you also in one of our next Q&A; sessions as well as in this Forum. Have a great weekend! Frank