MC-Board mit Ethernet

[BastelWastel]

Hallo vohopri,

vielen dank für den langen Beitrag
Nur eine Frage: Das IC3, ist das so eine Art pegelwandler?
Und ich befürchte, noch keine Passende Buchse für Ethernet - Anschluss zu haben. Ich habe mal gehört, dass da in bestimmten Buchsen ein kleiner Trafo drin ist. Ich hatte an eine Buchse aus einem alten Motherboard gedacht, würde das funktionieren?

Dann werd ich auch mal ein paar Versuche zum Thema Ethernet machen...

Mfg Thegon

Wenn du den Uebertrager mit verwendest kannst du das alte Ding da runteloeten,
wenn du aber eh bestellen musst..fuer den ENC oder so.. dann wuerde ich direkt 2-3 neue Buchsen mitbestellen.
Such nach MagJack, dann findest du welche mit integrietem Uebertrager..die kosten ned viel. Pollin Nr.: 450 001 z.B.

@vohopri
"meistens" ne falsche MAC, das klingt recht verdaechtig..
Hast du dir mal mit "arp -a" die ARP-Table angeschaut, vllt findet sich der Fehler wenn du weisst ob die falsche MAC im Netzwerk bekannt ist/wem sie gehoert etc..

[vohopri]

Nein,

was auf dem Kabel passiert, das weiss ich ganz genau. An das betreffende Segment hänge ich nur PC und mc board und ich sehe jedes Bit auf dem Draht im Netzwerk Protokoll Analyzer. Die arp Tabelle ist immer bekannt.
Das erste Paket nach dem Reset (arp oder auch andere ) hat eine korrekte src mac, und die folgenden eine falsche, die häufig wechselt.

Da wird etwas in der sw überschrieben.

Dadurch funktioniert http, das auf tcp aufbaut. Bei statischem arp Eintrag funktioniert es auch ohne Zeitbeschränkung.
Arp reply funktioniert 1x.
icmp echo funktioniert nicht.

Jetzt bin ich also beim Debuggen der sw und muss dazu mal etwas mehr C lernen.

[vohopri]

Nach dem optimieren der Programmgrösse, sehe ich keine falschen src mac adressen mehr. Allerdings antwortet der mc nicht immer auch arp requests. Die arp requests werden dann nicht erkannt. Das könnte ein reset problem sein. Um mehr zu erfahren und rationeller debuggen zu können, bau ich mir mal ein Peripherieboard dazu.

Bild hier  

So sieht der Anschluss der Pripherieboards aus.

[vohopri]

Nachdem ich jetzt ein wenig mehr Peripherie habe, ist das Debuggen komfortabler geworden.

Bild hier  

Die LEDs zeigen an, welche IP Pakete eingetroffen sind. So konnte ich schon Workarounds für Fehler im IP Stack finden. Mit allen Paketen auf dem Draht kommt der Stack nicht ohne weiteres zurecht. Aber mit Hilfe der Workarounds ist ein zuverlässiger Betrieb möglich.

Insgesamt habe ich jetzt ein funktionierendes IO Board mit Webserver und erweiterbarer Peripherie laufen. Und das freut mich schon sehr. Steuerung des MC und der angeschlossenen Geräte und Verbraucher durch PC oder Mobiltelefon über LAN, WLAN oder Internet ist jetzt möglich.

Mal sehen, wohin die Reise noch führen wird.

[021aet04]

Dein Projekt finde ich sehr interresant und verfolge es schon von Anfang an. Habe auch noch einige Ethernet Controller (bin mir nicht sicher aber es ist glaube der Gleiche wie bei dir). Weiter so und viel Erfolg weiterhin.

PS: Ich bin gerade am Löten einer meiner Optokopplerkarten für die CNC.

MfG Hannes

[vohopri]

Freut mich, wenns interessiert.

Inzwischen hab ich ein wenig mehr Peripherie.
Und durch sorgfältiges Konfigurieren des Netzwerks, kommen keine Pakete mehr, die das Board nicht verträgt. Das Programm hab ich ergänzt, so dass Pakete, die nicht verdaut werden konnten und das board unerreichbar machen würden, jetzt zu einem reset führen. Das ist nicht optimal, aber viel besser als vorher.

Das Entwicklungsziel ist natürlich, dass vollkommen unabhängig vom restlichen Geschehen auf dem Kabel, die eigentliche Funktion ohne reset erhalten bleibt.

[TheDarkRose]

Warum ein Reset? Sollte es nicht reichen einfach die Pakete zu verwerfen/ignorieren?