• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
netPI-netx-programming-examples update
#1
Hello there,

Could you please consider updating :
https://github.com/HilscherAutomation/ne...g-examples

Thanks a lot for your kind support.

BR,
Stéphane
  Reply
#2
Hi there,

what exactly do you mean with updating?

Is there any error you have detected?

Thx
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
(May-27th-2020, 02:38 PM)Armin@netPI Wrote: Hi there,

what exactly do you mean with updating?

Is there any error you have detected?

Thx

Hi Armin,

I mean that the image is one year old, based on Debian Stretch with an old version of the linux driver and quite old versions of firmwares.

So I would like it to be based on Debian Buster, with latest driver and firmwares and examples.

Like this one for example :
https://github.com/HilscherAutomation/ne...esys-basis

By the way, is there any chance CODESYS can use netX 51 some day ?

Thanks.

BR,
Stéphane from Hilscher France !
  Reply
#4
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
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

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

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
(May-27th-2020, 07:23 PM)Armin@netPI Wrote: >> 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

(May-28th-2020, 08:15 AM)Armin@netPI Wrote: 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
  Reply
#7
Hello Armin,

Looks like the cross-build stuff is gone from the Dockerfile in your last moves.

Since I'm building using amd64 in a cloud my build job fails :
https://gitlab.com/ada-for-automation/a4.../572185858

Is it a mistake or a fixture ?

Thanks for your kind support.

BR,
Stéphane
  Reply
#8
Hello Stephane,

the cross build "stuff" is still in there, but outsourced in a different file to be compliant with Docker Hub builds and its possibilities. (I learn every day more and more about Docker)

Now it is in the file https://github.com/HilscherAutomation/ne.../pre_build

Take this file on your AMD machine and  name it e.g. pre_build.sh and call it exactly one time prior your build process. It will install a QEMU processor emulator setup in a container and sets some references. After this you can start the build process as usual and it is no longer necessary to call the "old" start and end scripts located in the previous Dockerfiles during a build process any more.

This step is a prestep that is necessary if we want to support multiarchitecture capable containers builds in future as described here https://github.com/ckulka/docker-multi-arch-example

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#9
Hello Armin,

I have found this interesting :
https://community.arm.com/developer/rese...ith-gitlab

BR,
Stéphane
  Reply
#10
Hello Armin
I've check the commits in the examples repository, it seems that Ethercat FW package was just renamed, the content is the same and reported version is still 4.7.0.2
BR
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  NIOT-E-NPIX-4DI4DO with netpi-netx container WalterSchaefer 3 6,471 November-25th-2020, 01:06 PM
Last Post: zen89
  netX linux driver Irina Grinberg 4 3,469 May-7th-2020, 01:33 PM
Last Post: Armin@netPI
  [SOLVED] How to update firmware philippbruhin.ch 12 9,078 July-16th-2019, 11:20 AM
Last Post: patrick
  Software update without factory defaults hannes 3 2,761 March-19th-2019, 11:57 AM
Last Post: patrick
  [SOLVED] Use netX interface as profinet controller jromero248 2 3,110 January-10th-2019, 12:30 PM
Last Post: jromero248
  usage of hilschernetpi/netpi-netx-ethernet-lan is working but costs 25% cpu power Michael_d 7 4,901 March-9th-2018, 10:52 AM
Last Post: Michael_d
  Suggestion for NetPi Update process vdupont 3 3,125 February-14th-2018, 09:32 PM
Last Post: Armin@netPI
  Profinet Example in hilschernetpi/netpi-netx-programming-examples Thomas 2 3,661 November-18th-2017, 08:44 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)