Jump to content

[Erledigt] Ethernet Extension wird unerreichbar


fabian95qw
 Share

Recommended Posts

Guten Tag miteinander

 

Ich arbeite mit einem Masterbrick, mit Ethernet Extension & einem IO16 Bricklet.

 

Ich habe das Phänomen, dass die Ethernet Extension einem mehrtägigen Betrieb plötzlich unerreichbar wird, also auch nicht mehr Pingbar, während der Masterbrick via USB weiterhin normal ansprechbar bleibt.

 

Ich kann z.b. den Stapel im Leerlauf Laufen lassen, und am Folgetag ist er nicht mehr via IP erreichbar.

 

Ein Reboot Cycle (Power off & Power on), und die Extension Funktioniert wieder korrekt.

 

Ist die Ethernet Extension irgendwie defekt, oder ist das normal?

 

MfG

 

Fabian

Link to comment
Share on other sites

Hallo fabian,

 

verstehe ich dich richtig Leerlauf meint das du keine calbacks oder werte direkt abfragst ?

 

normal ist das nicht.

ich und ein paar andere haben das gleich Problem aber mit der Wlan Extension. bis jetzt wissen wir aber noch nix genaues.

 

du kannst uns aber noch mal sagen wie du den Stack ansprichst.

eigenes Programm?

wie hast du es da implementiert, am besten mal Code posten.

wie versorgst du deinen Stack mit strom? 

 

mfg

Masder

Link to comment
Share on other sites

Hallo fabian,

 

verstehe ich dich richtig Leerlauf meint das du keine calbacks oder werte direkt abfragst ?

 

normal ist das nicht.

ich und ein paar andere haben das gleich Problem aber mit der Wlan Extension. bis jetzt wissen wir aber noch nix genaues.

 

du kannst uns aber noch mal sagen wie du den Stack ansprichst.

eigenes Programm?

wie hast du es da implementiert, am besten mal Code posten.

wie versorgst du deinen Stack mit strom? 

 

mfg

Masder

 

Hallo Masder

 

Der Leerlauf ist wirklich ein Leerlauf, bis auf den externen Ping, welcher Prüfen soll ob die Ethernet Extension noch online ist.

 

Der Stack wurde via einem 5V Netzteil Versorgt, aber hatte eine extrem hohe Absturzrate (Reboot-Cycles) beim ändern von IO-Ports. Seit dem wir den Stack vom USB speisen, sind diese Probleme jedoch weg.

 

Der Stack wird via Java Code angesprochen, welcher alle 2 Sekunden die aktuellen Werte abfragt.

 

while(true)

{

List<SimpleIOPort> TIOPList = IOPList;

for(SimpleIOPort IOP : TIOPList)

{

RecvMask=IO16.getPort(IOP.getPort().charAt(0));

IRecvMask = new Integer(RecvMask);

Mask = Integer.toBinaryString(IRecvMask);

while(Mask.length()<8)

{

Mask = 0+Mask;

}

MaskArray = Mask.toCharArray();

if(MaskArray[7-Integer.valueOf(IOP.getPin())]=='1')

{

log.debug("The Pin of this Listener is currently 1");

//MEHR CODE

}

else

{

log.debug("The Pin of this Listener is currently 0");

//MEHR CODE

}

Thread.sleep(2000);

}

}

 

Ursprünglich war das Callbackinterface Implementiert, aber dieses hat im Zusammenhang mit dem dahinter liegenden Code nicht geklappt.

 

Es handelt sich hier um eine Implementieren für eine ==> Telefonanlage <==

 

Mit der Ethernetextension hatte ich nie Probleme. Da wuerde ich nochmals mit der Lupe suchen und schauen ob keine Kontakte im Westernstecker verbogen sind.

 

 

Der Loetkolben

 

Hallo Loetkolben

 

Ich gehe in der Zwischenzeit auch von einem HW Problem aus, auch u.a., da der gesamte Stack sich manchmal auch beim Schalten eines IO Ports resettet.

 

MfG

 

Fabian

 

 

Link to comment
Share on other sites

Hallo Bastian

 

Outputsmässig schalten wir Optokoppler

 

Wir hatten den Verdacht von Überspannung bzw. Störungsspannungen, deshalb sind wir ja auf USB Ausgewichen, wo es eigentlich nur 1/100 mal passiert.

 

Habe mal kurz ein Bild von meinem Konstrukt angehängt.

 

Ich konnte gerade beobachten, wie die Ethernet Extension stirbt.

 

Antwort von 192.168.X.X: Bytes=32 Zeit=1ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=1ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=1ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=1ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=318ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=236ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=155ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=87ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=297ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=217ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=135ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=54ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=280ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=5ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=2ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=33ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=4ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=4ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=98ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=6ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=3ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=169ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=81ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=4ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=227ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=144ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=64ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=3ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=1ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=123ms TTL=64

Antwort von 192.168.X.X: Bytes=32 Zeit=46ms TTL=64

Zeitüberschreitung der Anforderung.

Zeitüberschreitung der Anforderung.

<== Reboot Cycle ==>

Zeitüberschreitung der Anforderung.

Antwort von 192.168.250.190: Bytes=32 Zeit=998ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

Antwort von 192.168.250.190: Bytes=32 Zeit<1ms TTL=128

 

Mfg

 

Fabian

IMG_20161013_091048.thumb.jpg.d7c49f1fd9eea762a8e63936f4cd5fca.jpg

Link to comment
Share on other sites

  • 3 weeks later...

Hallo Loetkolben

 

CAT5 Kabel mit Schirmung

 

Sowas brauchen wir hier drüben in der Schweiz praktisch nie  :D

 

Das Problem hat sich auf jedem Fall gelöst.

Das ganze war auf einen regelmässigen IP-Konflikt mit einem Netzwerkgerät zurückzuführen, welches nicht immer im Netzwerk anwesend war.

 

MfG

 

Fabian

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...