• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[SOLVED] Lost physical fieldbus connection

I got the following problem:

When I ended working on the NetPi yesterday everything worked fine and I had a physical connection to my fieldbus switch and I was able to run the example "PNS_simpleConfig" and connect to my PLC. After I finished working on it I shut it down.

Today when I booted it again there was not and still is not even a physical connection to my switch. No LEDs are blinking. The switch does not show a connection on its port either.

What could have gone wrong? What can I do to enable the connection again?

Removing all Containers and all images and pull and run only the programming-example container again also did not work.

best regards
Hello, let us clarify the terms first of all.

You are talking about "fieldbus switch" ... so what is a fieldbus switch? ... is that a synonym for the two-ported Industrial Ethernet port of netPI for you?

You said you "shut it down". Do you mean you shut down the PLC or you shutdown the "PNS_simpleConfig" or the "fieldbus switch" ... this is unclear to me.

You say "no LEDs are flashing" ... which LEDs do you mean? The LEDs of the two RJ45 industrial ethernet ports? Or do you mean the LED bar on netPI's front? What is the status of the LEDs ERR, RUN, APL and SYS? These 4 LEDs are controlled specifically by the Industrial Ethernet controller embedded in netPI, so they tell us the most valueable information

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

Hello Armin,

sorry that i expressed myself unclear. With fieldbus switch i meant - to be exactly - an ET200S from Siemens on which my NetPi is connected.

I shut down both the PLC and the Netpi.

Both the LINK and the ACT LED of the Industrial Ethernet port of the NetPi are missing.

The ERR LED is off. The RUN and the APL LED are off as well.
The SYS LED flashes yellow and green alternately. According to the User Manual, this means that the Real-Time Ethernet processor is waiting for firmware. But I have installed it via the mentioned container with the command: dpkg -i netx-docker-pi-pns- ?

Based on the status of the LED SYS the Industrial Ethernet controller has lost its firmware (by whatever reason). This controller has an internal memory where the firmware is loaded into when any of the programming example is started. This is done automatically by the driver when the function xDriverOpen() is called as initial call in any example program.

So using the command dpkg -i netx-docker-pi-pns- is indeed not enough. This just copies the firmware to the right location (/opt/cifX...) and allows the driver later to find it and to start the firmware load procedure when xDriverOpen() is called the first time again by your user application.

So just call your application and the firmware gets loaded.

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

So starting the programming example should get the connection running?

Even after starting the example I have the same problems.
The example program from github automatically installs the correct firmware when ./PNS_simpleconfig is called. And it also outputs to the console errors in case there is a problem detected. Which error is reported by the test program?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Well, I started the example again to copy the error messages for you ... and now it works.

I did absolutely nothing else, just started the program again. I hope it will work in the future aswell.

If it is not working again tomorrow I think I need to contact you again and then I will have the Error messages for you. But for now i think I can work with it. Still I would be happy about any advise or reasons why it could not connect in the attempts before.

But thank you very much for your support.
Loosing the Industrial Ethernet controller's firmware is indeed very very unusual. Once a firmware has been loaded and saved in the controllers FLASH memory it resists there forever.

Here are the only three scenarios I see as possible:

* tried to load a firmware that does not fit to the type hardware in use. For example tried to load a netHAT firmware into netPI
* interrupting a firmware download procedure that is in progress and hence get incomplete
* use a special command to delete the firmware manually
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

But can you please repeat how it happened that apparently the firmware got lost?

You said your ET200S PLC was connected to netPI and was communicating. (Was netPI the only PROFINET io device connected by the way?)
Then you switched off the power of netPI? Or the PLC? Or both at the same time?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


Forum Jump:

Users browsing this thread: 1 Guest(s)