Hilscher Community Forum
Fieldbus Ports not working - Printable Version

+- Hilscher Community Forum (https://forum.hilscher.com)
+-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html)
+--- Forum: Software (https://forum.hilscher.com/forum-5.html)
+--- Thread: Fieldbus Ports not working (/thread-512.html)

Pages: 1 2


Fieldbus Ports not working - Schoko - October-23rd-2019

Hello,

i have to use the Fieldbus Ports as normal Ethernet Ports. I installed the Docker Container as explained here: https://github.com/HilscherAutomation/netPI-netx-ethernet-lan

I cant get any access to the ports, not even the LED of the Ports are blinking

With another netPi RTE3 its working.

Docker Log:
starting ssh ...

Starting OpenBSD Secure Shell server: sshd.

Waiting for added 'cifx0' network interface ...

'cifx0' network interface not ready in time

nnot find device "cifx0"

nnot find device "cifx0"

cifx0 ip address/subnet mask set to 192.168.140.6/255.255.255.0



RE: Fieldbus Ports not working - Armin@netPI - October-23rd-2019

Well, the netX controller chip on netPI RTE 3 has 4 LEDs that are basically telling in which state the industrial network controller chip is.

Those are the upper four LEDs on netPI's front named NS, MS, APL and SYS. Please tell me the status of these?

Also very important is that no other container is using the netX controller the same time the LAN container occupies the netX for its purpose. Can you confirm?


RE: Fieldbus Ports not working - Schoko - October-23rd-2019

The SYS-LED is blinking Green/Yellow.
The LAN Container is the only one that is running.


RE: Fieldbus Ports not working - Armin@netPI - October-23rd-2019

Well LED flashing green/yellow means the netX chip is not loaded with any firmware or software. So in this case it is quite natural that your two RJ45 ports do not indicate any LED activity since the PHYs are not enabled.

By default netPI RTE 3 is delivered with a PROFINET IO device firmware loaded in netX controller. For me a flashing LED green/yellow means that there was indeed a try from any host software package to load a new firmware to the netX chip ... which apparantly was your LAN container. At the moment I have no explanation why it failed.

But with flashing green/yellow netX chip is still operational and waiting to accept a new software. So what is if you restart the container ... what happens then in the log file?

Thx
Armin


RE: Fieldbus Ports not working - Schoko - October-23rd-2019

It was blinking from the first start.
With a restart of the container the log shows the following:
Starting OpenBSD Secure Shell server: sshd.


Waiting for added 'cifx0' network interface ...


'cifx0' network interface not ready in time


nnot find device "cifx0"


nnot find device "cifx0"


cifx0 ip address/subnet mask set to 192.168.140.6/255.255.255.0


terminating ssh ...


Stopping OpenBSD Secure Shell server: sshd.


starting ssh ...


Starting OpenBSD Secure Shell server: sshd.


Waiting for added 'cifx0' network interface ...


'cifx0' network interface not ready in time


nnot find device "cifx0"


nnot find device "cifx0"


cifx0 ip address/subnet mask set to 192.168.140.6/255.255.255.0


RE: Fieldbus Ports not working - Armin@netPI - October-23rd-2019

Well, before the netPIs are packaged in the cardboard box the two RJ45 ports are physically tested with a loop ethernet cable. So the chip must have been worked well.

I cannot exclude that meanwhile something happened with your netX chip, its internal security chip and and and... . This is the first time I see a netX chip of being not loadable any more on netPI.

So I can just recommend you to send back this device to hilscher repair and you will get an immediate replacement. Sorry for this inconvenience.

Before you send it back, can you please tell me the MAC address that is printed outside on the label please.

Thx
Armin


RE: Fieldbus Ports not working - Schoko - October-23rd-2019

Thanks Armin,

the MAC-Address is: B827EBCEA272


RE: Fieldbus Ports not working - Armin@netPI - October-29th-2019

Hello Schoko,

I got your device you sent back and examined the unit.

Based on the written log file under /opt/cifx/cifX0.log I found out that indeed loading the firmware into netX controller failed.

The first thing I did was to modify the container in that way that the driver in case of such an error also outputs the log file to the Web-GUI in order to have better diagnostics in future.

The log file contained the following error:
28.10.2019 14:41:09.517.679: Error downloading firmware to device '/opt/cifx/deviceconfig/FW/channel0//R160D000.nxf'- (lRet=0x00006196)!

Based on internal Hilscher documentation the referenced error 0x00006196 means "File system inconsistent, needs reformatting". In other words the firmware download procedure is not able to load a firmware since the file system in netX controller is corrupt by any reason (maybe power loss during firmware download).

I changed the cifX0deamon application now accordingly to send a format command to netX controller whenever it indicates not to have a valid firmware running. With this new setup I got your device back into running state and netX SYS LED is now static green as it should. With this new daemon a recovery is handled automatically in future in case a netX file system is getting corrupt.

Thx
Armin


RE: Fieldbus Ports not working - EnergyKonnex - June-29th-2020

Hi Armin,
I have been experimenting with the NIOT-E-NPI3-51-EN-RE in my spare time, mostly with node-red and the RS-485 module. I have noticed the ERR/NS communication status Real-Time Ethernet has always been blinking red. Over the weekend I was trying to use the router functions but I don’t see the other Ethernet ports in the web based management.
I only have access to eth0. When I open de router options, I get the following error ”Error quarrying active devices”.
Any Idea? I am using Firmware version       V1.2.0.0
Gr,
Duncan.


RE: Fieldbus Ports not working - Armin@netPI - June-29th-2020

Which firmware did you load into the netX controller that is assembled on the NIOT-E-NPI3-51-EN-RE board additionally?