Wenn eine Option nicht wählbar ist [-], liegt es in der Regel daran, dass eine notwendige vorherige Option nicht aktiviert wurde. Z.B. kannst Du bestimmte Applikationen nicht nutzen, wenn UDP nicht aktiviert wurde. Eine dirkete Übersicht habe ich auf der Ethersexpage auch noch nicht gefunden. Alles leider sehr empirisch, das ist bei dem Projekt aber auch das Problem 
Gruss
Bernd
Da ich mit denselben Fragen „kämpfe“:
werde ich mich wohl auch mit dem ESX-Projekt beschäftigen.
Eine wesentliche zusätzliche Frage, die ich habe - vielleicht kann die hier jemand beantworten:
Ich würde gerne mittels AVR-Net-IO auch die Serielle Schnittestelle via LAN „verlängern“, um damit im Heizraum eine einzige Platine zu haben, mit der ich einerseits Pumpen und Licht Steuern kann und andererseits auch mit der Heizungsanlage (Wärmepumpe Stiebel) via RS232 kommunizieren kann.
Ist im Ethersex solch ein „Modul“ drin oder nutzt es die RS232 nur zur Kommunikation PC <-> AVR?
Danke
jwka
Hallo, habe mich nun etwas beschäftigt mit E6, und auch dabei mit dem Control6, sieht sehr vielversprechend aus 
serielle schnittstelle kann es laut doku weiterleiten siehe YPort - zerties.org
die [-] Probleme habe ich mittlerweile auch schon rausgefunden
Für den bootloader braucht man den nächst größeren ATMEGA (werde ich mir nächste woche gleich mal ordern, in verbindung mit zusäzlichen Boards )
und das „Watch IO changes (and react)“ hätte ich auch schon aktiviert bekommen, allerdings werde ich gleich alles per CONTROL6 Script lösen …
Hast Du sowas wie ein „Protokoll“ oder „Things to be done“ zusammengestellt, das hier vielleicht mal zu veröffentlichen wäre?
Es würde dem einen oder anderen (u.a. mir) vielleicht die eine oder andere schlaflose Nacht ersparen.
Und noch ne Frage: MUSS ich denn mit Linux oder kriegtman das Ganze auch unter WinXP zum fliegen? Grundsätzlich habe ich das für das Pollin Board nämlich hier am laufen …
Danke
jwka
meinst du mich?
Also ich bin gerade erst beim Testen der ganzen einzelnen Komponenten vom E6, Control6, versenden per UDP, versenden per TCP usw. … sobald ich was habe, mit dem ich dann anfangen kann, werde ich mich melden
Ich habe mir die Live CD in einer virtuellen Umgebung isntalliert - das klappt wunderbar - das flashen ist etwas mühseliger, da ich in der VM keinen Com port habe, und so immer das file zuerst auf meinen lokalen rechner kopieren muß, und von dort dann flashen muss - das ginge sonst auch automatisch …
(Es geht glaub ich auch auf WinXP, aber ist sicher nicht gerade einfach zu installieren, mit dem cygwin und co)
Aber bislang bin ich mächtig beindruckt von dem E6 samt Control6 und co …
Ich glaub es war die richtige wahl (hatte auch schon einige komponenten von iSysBus hier rumliegen - das wäre auf CAN Bus … aber so find ichs besser 
)
So, habe nun einiges rumgebastelt
Ich habe mir mal überlegt, wie ich die Daten von Änderung möglichst schnell vom E6 zu IPS bekomme und mir sind vorerst mal folgende sachen eingefallen
[ul]
[li]Direkt per UDP
[/li][li]Direkt per TCP
[/li][li]ECMD UDP
[/li][li]ECMD TCP
[/li][/ul]
Direkt per UDP habe ich die befürchtung, das mit einmal Senden oft pakete verloren gehen, auf eine Rückantowrt zu warten und co ist mir zu komplex.
Direkt per TCP ist mir im Control 6 und co auch zu komplex, vorallem die Fehlerprüfung, falls mitten drinnen mal der Empfänger nicht mehr erreichbar ist.
ECMD UDP - Wartet automatisch auf eine Antwort vom empfänger, und verschickt bis zu 12 Mal die Paketem falls diese Antwort nicht ankommt.
Aber das problem ist, man kann maximal 1 Paket gleichzeitig senden, das nächste Paket kann erst dann wieder gesendet werden, wenn das vorherige abgeschlossen wurde (12 mal gesendet oder rückantwort erhalten) - die nächsten Pakete werden einfach verworfen.
ECMP TCP - Wartet auch auf die Antwort vom Empfänger - Vorteil gegenüber der UDP Varainte, es könenn bis zu 3 Pakete gleichzeitig versendet werden.
Daher habe ich mir für mich mal folgendes überlegt im contro6 Skript baue ich mir einen Sendebuffer zusammen, der sofort verschickt wird.
Muß im nächsten Zyklus wieder was versendet werden, dann wird das erst im SendeBuffer gespeichert, und erst nach 5 Zyklen dann an den PC versendet.
Wobei immer zuerst die Eingänge geprüft werden, und dann die Ausgänge (falls ein Eingang einen Ausgang schaltet, wird beides gleichzeit versendet)
Im Sendebuffer werden die Befehle (möglichst kurze) einfach per # getrennt.
Die Defaultmässigen PIN_RISING und co, werden nicht verwendet, da ich ein Softwaremässiges entprellen drinnen habe, zumindest bei Tastern und co, wobei bei Tastern SOFORT geschaltet wird also wenn die auf HIGH gehen, wirds sofort übernommen, und erst beim HIGH->LOW wird entprellt (muß dann xx zyklen anliegen damits übernommen wird)
Ein kurz/lang drücken benötige ich nicht
So das war m al kurz der Status
Nun warte ich das pollin die AVR-Net Bausätze wieder Lagernd hat, damit ich für die produktiven bestellen kann.
Und der nächste schritt ist auch mal hardwaretechnisch zu überlegen wie ich die Taster die mit 230V beschaltet sind in den AVR-Net Eingang reinbekomme.
Auch einen ATMEGA 644 muß ich mir dann bei pollin besorgen, den ich will das System auf jeden Fall mit nem Bootloader ausstatten -> keine Lust später im Pool schacht oder wo auch immer mit dem Notebook rumzukrabbeln
Klingt gut, ich kann aber das Thema „Paket verloren“ bzw. sichere Übertragung nicht qualifiziert kommentieren, weil ich das Control6 usw. noch nicht kenne und damit auch nicht weiss, wie man wo eingreifen kann.
Ich hätte jetzt gedacht, dass man das Thema „Quittung“ einfach mit ner zusätzlich getimerten Routine abfangen kann und nach XX Zyklen schlicht das Paket wieder und wieder sendet.
UDP hat doch, wenn ich recht erinnere auch ne Sequenznummer, die man in einer Liste halten und aktualisieren kann? Kommt dann die Quittung des UDP Paktes zu spät, ist einfach ein zweites schon raus und die Quittung des vorherigen wird ignoriert (oder für das zweite schon mit verwendet)?
Man müsste dann in das Datenpaket ne eigene Sequenznummer einbauen und prüfen, ob man die schon mal empfangen hat. Wenn ja, ist nur ne Quittung zu schicken, wenn nein, ist der Datensatz auszuwerten.
Zusammen mit „Alive“ Messages, die regelmässig kommen, könnte dann auch eine Garbage Collection über Sequenznummern erfolgen bzw. sogar erkannt werden, welche Paket-Nummern verloren gegangen sind.
Im Sinne der Zuverlässigkeit wäre das ja eine relevante Info, denn wenn ich ne Device habe, wo viele Pakete verloren gehen, ist da ja auch ein Hinweis, dass da auf der Strecke was nicht stimmen kann.
Dass ein noch keine weitere Methode gibt, wundert mich ein bischen. Ich finde auch dass zwischen der „permanenten“ (Socket) und „zufälligen“ (UDP) Verbindung noch irgendwie was fehlt.
jwka
Ich glaub ich werde einen Teil der Intelligenz dann auch ins IPS auslagern, sowie die IsAlive Meldung - sprich ich werde einfach jede Minute dann per TCP/ECMD die aktuellen Ports und Temperatur und co (die ich nicht per Änderung haben will) nach mal validieren.
Da kann ich dann falls wirklich irgendwo irgendwie doch mal was verloren ging, den Status aktualisieren.
Für die ersten Versionen werde ich mich mal auf das ESEND bzw ECMD PRotokoll verlassen und mal schaun, wie es sich im Echtsystem dann macht (immer mit der Absciherung das ich jede Minute zu 100% die richtigen Werte habe, oder eben weiss, das die Verbindung sowieso tot ist … )
Bin sehr an Deinen Ergebnissen interessiert.
Ich denke, wir sollten im neuen Wiki da auch Ergebnisse und How-To’s einstellen, denn diese Technik ist eigentlich hichinteressant aber auch mit viel Initialaufwand verbunden, was sicher viele (ungerechtfertigt) abschrecken dürfte.
jwka
So, mal zwischenbericht
Heute angekommen 5NetIO und 7ATMEGEA 644
Gelich so nen ATMEGA 644 in das bestehende NetIO reingesteckt, rumprobiert, rumprobiert rumprobiert
und der Bootloader läuft - genau so wie es sein sollte.
Beim hochfahren des Bootloaders, holt er sich das File vom TFTP Server ab und fertig …
Nächste Schritte sind nun, schaun, das die Ausgänge und Eingänge mal so funktionieren wie sie sollen (Optokoppler, Relais und co)
werde auch die platine des NetIO’s verstümmeln (abfräsen, und dranlöten von den PIN’s zu einer Ausgangsplatine), da ich noch Hutscheinengehäuse und fertige Platinen von einem anderen Projekt habe, wo schon Optokoppler drauf sind … mal schaun, ob sich da was basteln lässt
Platine verstümmeln vom Net-IO? Oder von der Relaiskarte?
Mein Net-IO Projekt sollte längst gestartet sein, zweie liegen hier rum … ich hoffe, dass es in 2-3 Wochen soweit ist, dass ich da dran komme.
Ich verfolge Deine Posts mit Spannung!
jwka
Vom NetIO, damit diese in das Hut Schienen Gehäuse rein passt
Werd ich auf allen seiten ein bisschen was wegschneiden, und natürlich auch nur das bestücken, was auch wirklich gebraucht wird …
wenn das funzt könntest Du mal als T&T hier einstellen und ein Bild machen?
Sowas ähnliches schwebte mir auch schon vor.
Alledrings kriegt man den „normalen“ IO ja quer auch in ein etwas größeres Hutschienengehäuse (8 TE?) ohne Modifikationen. Es blabt halt sehr viel Raum ungenutzt.
Bin sehr gespannt, denn ich brauche für den Heizraum und das Poolhaus noch ne Lösung und da ist der NetIO vorgesehen.
jwka
eins muß ich auch vorher noch mal testen - den 1wire … für die DS1820iger.
Ja das mit dem gehäuse stimmt schon,aber ich habe eben hier diese Gehäuse und eben die genau passenden Grundpaltinen vom iSysBus projekt, und da verwende ich dann gleich die klemmen, optokoppler, Relaistreiber und die 5V DC/DC Wandler, der da daruf ist, da ich glaub 4 solcher fix fertig aufgebaut habe, und eben nicht merh verwenden werde …
so, 1wire funktioniert auch auf anhieb … so wie es sollte
Hallo,
ich wollte ja eigentlich auch mein Gebastel wieder aktivieren und in IPS integrieren aber zur Zeit ist einfach zu viel los.
Ich habe hier auch einige AVR-NET-IOs mit den diversen ADD-ONs und daran schon verschiedenste Webserversoft getestet und ein bißchen rumprogrammiert.
Aber für die Hutschiene finde ich Ulrich Radigs Lösung deutlich geeigneter, da dafür geplant. Zudem klappt das mit der SD-Anbindung auch sofort ohne Rückschläge.
Wenn sich mal doch wieder Zeit bietet, öffne ich mal wieder meine Unterlagensammlung. Zwischenzeitlich lese ich einfach mal mit.
Na, wenn wir jetzt schon ein bischen plaudern:
Ich habe hier noch zwei ARM Cortex (mbed NXP LPC1768) rumliegen und einen Texas Instrumets MSP-430.
Beide Teile haben Platinen mit gerade mal ein paar cm Abmessungen - passen prima in den Eckel-Teil eines HS Gehäuses.
Speziell vom ARM versprech ich mir einiges. Die Website hat tolle Unterlagen wie cookbook, codebeispiele etc. Im Internet gibt es auch tutorials.
Wenn das Teil hält, was es verspricht, werde ich damit einiges machen. Habe gerade eh ein paar Bilder für meinen Besuch bei Investoren in Deutschland gemacht, hänge die mal an …
Ciao
jwka
So, bin schon mal ein großes stückchen weiter …
Hier mal der aktuelle Stand
Habe ATMEGA 644 im Net IO drinnen, der Bootloader olt sich immer brav die neuerste Version, wenn er eine findet ab.
Beim Starten und alle 60 sekunden schickt er einen PING an den Server.
Der Server prüft alle 60 sekunden, ob der ping 2*ausgefallen ist, wenn ja, dann setzt er mal eine AKTIV Variable auf FALSE.
Gleichzeitig werden alle 60 Sekunden alle 1wire devices abgefragt und in IPS Variablen geladen (Dies erfolgt mit einem einzigen Clientsocket, wo er nach der reihe AVR IO nach AVR abfragt und 1wire device nach 1wire device)
Im ATMEL ist ein contro6 script drinnen, das so sachen wie Lichtstuerung macht (Taster entprellen, und Licht an/aus)
Bei Änderung vom Ausgang wird dieser an den SERVER geschickt.
Wenn bestimme Eingänge geändert werden werden die auch per Control6 script an den SERVER geschickt.
Der Server ist in diesem Fall ein kleines Delphi programm, das die Daten entgegen nimmt, dem AVR ein OK zurückschickt und dann das ganze an IPS weiterschickt
IPS schreibt die Daten dann in die Variablen rein.
Wenn sich Daten sehr sehr schnell ändern, habe ich es mal so gemacht, das die erste meldung sofort kommt, und die nächste meldung dann mit ca. 200 ms verzögerung.
Ich werde das ganze mal hier im Büro einem Dauertest unterziehen und schaun wie stabil das ganze läuft
Der große wehrmutstropfen ist im moment, das ich das zusätzliche programm brauche, da in IPS leider die ServerSockets sehr beschnitten sind - und ich aber im AVR das ECMD Protokoll verwenden will, um sicherzustellen, das alle Befehle auch sicher ankommen.
Was noch abgeht, ist das erste synchronisieren der variablen, falls der AVR Ne mal neu gestartet wird, oder IPS mal neu gestartet wird.
Hallo,
habe das ähnliches vor. ich bekomme nun auch schon eine socket verbindung zum avr-net-io (ethersex) hergestellt.
Jetzt habe ich aber noch nicht so richtig eine Vorstellung wie ich die ecmd befehle via socket an das arv-net versende.
mein Versuch die Befehle als bytearray zu senden ergab zwar keinen Fehler hat aber auch nicht den gewünschten Erfog gebracht.
hat da Jemand eine Idee?
byte setport50 = { Convert.ToByte(‚e‘), Convert.ToByte(‚c‘), Convert.ToByte(‚m‘), Convert.ToByte(‚d‘), Convert.ToByte(’?’), Convert.ToByte(‚i‘), Convert.ToByte(‚o‘), Convert.ToByte(’ ‚), Convert.ToByte(‚s‘), Convert.ToByte(‚e‘), Convert.ToByte(‚t‘), Convert.ToByte(‘ ‚), Convert.ToByte(‚p‘), Convert.ToByte(‚o‘), Convert.ToByte(‚r‘), Convert.ToByte(‚t‘), Convert.ToByte(‘ ‚), Convert.ToByte(‚2‘), Convert.ToByte(‘ '), Convert.ToByte(‚0‘), Convert.ToByte(‚3‘) };
sock.Send(setport50);
Grüße
bodo2
