netPI-netx-programming-examples update

[slos]

>> Hi Armin,
>> Thanks for your detailed answer.

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.

>> My purpose is not only to show but to use as well.
>> Indeed, this thread was started because the docker image I was trying to build based on yours failed because of old tool chain version.
>> You may know my own project :
>> https://gitlab.com/ada-for-automation/ad...automation
>> https://slo-ist.fr/ada4automation/a4a-ne...-container

>> It has a netPI RTE builder based on your image :
>> https://gitlab.com/ada-for-automation/a4...te-builder

>> And the job failed because of not supported new tool option
>> https://gitlab.com/ada-for-automation/a4.../567205968

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 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 the netX developers 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.

>> Indeed, if one wants to use RT process he has to use privileged mode like when using CODESYS.
>> Yes, newest version of the Linux driver offers interrupts management for SPI but this is not mandatory and one can perfectly continue using polling.
>> What I would find confusing is using old driver version, meaning old documentation.

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.

>> We at Hilscher France are advocating the use of netPI as a powerful edge gateway which one can use to build his very own solution and we are very happy to use what you provide as a starting block.
>> It's important to us that it features rather up to date versions even if we know how to update by ourselves.
>> Then the customer can use whatever language or tool he wants.

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.

>> Yes, it does make sense to me as a support guy since I can't support all that hell.

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.

>> I know, I know :
https://slo-ist.fr/hilscher/raspberry-pi-codesys-al

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.

>> That makes sense too but since Hilscher is in touch with CODESYS since years, you could know of some development.
>> It seems not. This is unfortunate since netPI RTE could be used as a programmable gateway.

Since they have all slave stacks running natively on any Ethernet port anyway ... so why to integrate netX51 then? Makes no sense.

>> Well, this is not accurate. They have several interesting stacks but no EtherCAT Slave to my knowledge.
>> Some of our customers want to connect legacy CANopen devices using CODESYS on netPI RTE to higher level EtherCAT Master.
>> So, they are interested in the EtherCAT Slave provided by netX 51 but then they are facing a wall.
>> Node-RED is no go. It is possible to create a CODESYS driver or use Modbus TCP as a bridge.
>> Ada for Automation provides such bridge :
>> https://gitlab.com/ada-for-automation/ad...a4a-k7-wui
>> It features cifX interface, Modbus TCP Client, CODESYS would be configured as server, and a web UI fr cifX Status, Modbus TCP status and application status.

>> Of course, since I have used CODESYS on netPI RTE with EtherCAT Master, PROFINET IO RT Controller, Ethernet/IP Scanner, Modbus TCP Client and Server, Modbus RTU Master and Slave, I know that this combo could satisfy many customers needs.
>> And with all the Linux ecosystem available.

Thx
Armin

>> Best regards,
>> Stéphane

---

I have started updating the repo right now. It now has a new look as all the other newest repos

Thx
Armin

Hi Armin,

That's great !

I will rebuild my images as soon as you have finished updating !

Thanks a lot.

BR,
Stéphane