May-27th-2020, 07:23 PM
(This post was last modified: June-3rd-2020, 10:10 AM by Armin@netPI.)
Well if you know Linux well then you know that just for showing the coprocessor netX51 working it doesn't matter if it is jessie, stretch or buster or the latest version debian bullseye. Nothing in the Linux commands used in the container has been changed in these four versions ... any would be feasible.
The latest netX driver has been extended by interrupt functionality to speed up TCP/IP communications in netX TCP/IP mode on Ethernet frame reception. But the examples provided in this programming example container work in request/response IO process data exchange mode where interrupt mode is not speeding up anything. Drawback of the latest driver is that it needs more explanation cause of the interrupt function ... so I don't know if this would confuse all the netX developers to much since the GPIO pin needs to be configured then in the container additionally requiring the container to run in "privileged" mode also. What might be possible is to run the driver in non-interrupt mode but I have to test that first before releasing it.
Updating the firmwares would be the only argument to recreate the container while keeping the rest untouched. You can see that many thoughts need to be spent if a container should get an update or not.
To your CODESYS question:
With the release of netPI four years ago the decision has been made not to support any containerized third party apps someone would ever deploy on netPI. So as with CODESYS. The same would apply for apps like Node-RED, python, java, javascript and and and.
Correct is that we offer a CODESYS container, but if you analyse the CODESYS container well you see that we are just providing an "empty" container hull with just an SSH server pre-installed. Further integration of the CODESYS PLC logic is in the hands of 3S company and Hilscher would never investigate on what they integrate in their CODESYS. We would never push 3S as 3rd party to integrate a netX51 driver in CODESYS. They have to make this decision by themselves ... and of course need to see any advantages for them in making money. Since they have all slave stacks running natively on any Ethernet port anyway ... so why to integrate netX51 then? Makes no sense.
Thx
Armin
The latest netX driver has been extended by interrupt functionality to speed up TCP/IP communications in netX TCP/IP mode on Ethernet frame reception. But the examples provided in this programming example container work in request/response IO process data exchange mode where interrupt mode is not speeding up anything. Drawback of the latest driver is that it needs more explanation cause of the interrupt function ... so I don't know if this would confuse all the netX developers to much since the GPIO pin needs to be configured then in the container additionally requiring the container to run in "privileged" mode also. What might be possible is to run the driver in non-interrupt mode but I have to test that first before releasing it.
Updating the firmwares would be the only argument to recreate the container while keeping the rest untouched. You can see that many thoughts need to be spent if a container should get an update or not.
To your CODESYS question:
With the release of netPI four years ago the decision has been made not to support any containerized third party apps someone would ever deploy on netPI. So as with CODESYS. The same would apply for apps like Node-RED, python, java, javascript and and and.
Correct is that we offer a CODESYS container, but if you analyse the CODESYS container well you see that we are just providing an "empty" container hull with just an SSH server pre-installed. Further integration of the CODESYS PLC logic is in the hands of 3S company and Hilscher would never investigate on what they integrate in their CODESYS. We would never push 3S as 3rd party to integrate a netX51 driver in CODESYS. They have to make this decision by themselves ... and of course need to see any advantages for them in making money. Since they have all slave stacks running natively on any Ethernet port anyway ... so why to integrate netX51 then? Makes no sense.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
