Hallo Torro, …ach so, ich dachte dies basiert auf IPS und hat jetzt nichts mit Dallas zu tun oder so! :rolleyes:
Hallo Hinti,
nein, das sind Einstellungen im Treiber…
Hmm … was für ein RC Glied nimmt man denn da oder welche Drossel?
Ub vom 1w Modul?
Jens
…daß hat es eher verschlechtert. Eine leichte Verbesserung brachte ein 100n direkt am DS18B20.
Die Spannung ist exakt 5V (mit und ohne 100n).
Leider gingen mir die 100n aus, und so bleiben noch ein paar ohne.
Die Fehler sind zwar jetzt weniger (mit Treibereinstellung wieder auf ‚normal‘), aber trotzdem noch eher häufig.
Ich glaube ich versuche mal den Data-Ground mit dem Powerground zu verbinden. Derzeit sind sie das nämlich nicht!
Klugschnakkermodus an:
Diese Maßnahme ist immer richtig, hatte ja Torro auch schon empfohlen.
Kannst auch noch einen kleinen Elko 10µF versuchen, schaden kann es nicht.
Messtechnisch müßtest du einen Osziliscope nehmen um ev. was festzustellen.
Versuch macht kluch 
@Jens (Tetrapack)
Die LED`S werden sicher mit PWM „gedimmert“.
Da solltest du mit eine Kombination von min 100µF Elko und einem 100nF Kondensator Erfolge haben.
Hast du viel Strom, sprich Last, wäre eine grösserer Elko noch besser.
Viel Laststrom -----> viel Müühkro (Elko)
Es sind es die steilen Flanken der PWM die die Störungen verursachen.
Ein Widerstand parallel, hält die Abschaltspitzen klein, den, wie auch die Elkos an die Ub des Lastkreises.
Am 1Wire nur die oben geschriebene Maßnahme.
Klugschnakkermodus aus.
Vergesse auch immermal diese Maßnahmen, aber wenn Störungen da sind, komme ich wieder drauf. 
Hi,
ich kann´s nicht lassen und muss meinen Senf dazu jetzt auch mal absondern.
Die ersten Versuche mit 1-Wire gingen bei mir vollends daneben. Auf dem Weg der Fehlersuche stolperte ich, als Hoffnungsschimmer über:
die Application Note AN148 des Herstellers
und hoffte auf Seite 8 mit der dort aufgeführten R/C Kombination mein Glück zu finden.
Dem war leider nicht so, es stellte sich letztendlich heraus, dass mein Gericom Supersonic 1000 mit seinem 1.1er USB Port nicht in der Lage war, den 1-Wire USB Adapter zu bedienen. Das Netz läuft seitdem mit anderen Rechnern, aber immer noch provisorisch zusammengesteckt auf einem Breadboard MIT dieser R/C Kombination problemlos. Ein zweiter Strang ist über einen XPort auf einer bestückten IPScom in Betrieb.
Zur Einstrahlung durch Störimpulse:
Hier bietet sich natürlich verdrillte Leitung an, da die Störimpulse sich, quasi mit jeder Drehung, selber aufheben. Zusätzliche Schirmung, wie ab CAT 5 vorhanden, blockt natürlich weiteres ab.
Mir ist durchaus bewußt, dass ich mit
meinem Vorschlag der Nahverdrahtung
gegen diese Grundregeln verstoße, es läuft aber problemlos in der Praxis.
Wobei wir beim nächsten Thema sind:
die Vergleichbarkeit von euren Aussagen.
Den einen stört das Windrad in 800m Entfernung zum Haus, weil bei der untergehenden Sonne die sich drehenden Flügel in der Zeit zwischen 17,28 und 17,45 Uhr als Schatten im Wohnzimmer niederschlagen; er deshalb depressiv wird und den Klageweg einschreitet (kein Scherz, so etwas ähnliches hat es gegeben),
der andere sagt sich: wenn 50% der Messwerte für mich nutzbar sind, dann ist das für mich in Ordnung.
Was wir brauchen ist ein Referenzscript welches diese Probleme als Zahlenwert ermittelt und bei allen läuft:
DANN haben wir eine Basis!
Als Beispiel poste ich mal ein von mir abgewandeltes Logscript, als Basis diente ein Beispiel für die V1 aus dem Forum:
<?
$separator = „;“; // separate fiels by ; - good for Excel
$leerzeichen = " "; // ein Leerzeichen
{
$IPS_Value = GetValueBoolean($IPS_VARIABLE)? „1“ : „0“;$handle = fopen("…/logs_var/" .$IPS_VARIABLE. „.txt“, „a“);
fwrite( $handle, date(„d.m.y“).
$leerzeichen.
date(„H:i:s“).
$separator.
$IPS_Value.
"
");
fclose($handle);
} ?>
Dieses Script erzeugt im Unterverzeichnis /logs_var eine Datei mit dem Namen des aktuellem Datums samt Uhrzeit, der ObjektID der aufrufenden Instanz und der Endung.TXT.
Getriggert wird das auf Änderung des Wertes. Als Ergebnis habe ich z.B. eine Datei, in der ich sehen kann, wann das Fenster im Badezimmer geöffnet bzw. geschlossen wurde. Sollen andere Werte geloggt werden, so reicht es, auf diese zu triggern.
Dieses Prinzip sollten wir auf unser Problem übertragen:
Bei jeden Zugriff wird ermittelt, klappte das oder ging der Versuch mal wieder daneben. Das Berechnen des Ausfallprozentsatzes innerhalb des Scriptes sollte auch kein Problem sein.
Besser wäre natürlich eine Speicherung der Daten innerhalb einer SQL Datenbank, so wie Bruns8234 es vorgestellt hat.
Auswertungsmöglichkeiten, wie z.B. die Frage, wann treten diese Fehler vermehrt auf, würden die Fehlersuche erheblich erleichtern.
Die Krönung wäre eine eigene Seite, so wie die SQL Serverseite als Unterlink auf einem Browser, bei der man zusätzlich noch die Kabellängen und Positionen der einzelnen Sensoren eingeben könnte. Der Traum jedes Technikers zur Analyse und Fehlersuche.
Hat jemand Lust das umzusetzen?
ich bin da eher der Generalist mit dem Gesamtüberblick, dem Blick für Schwächen und der Gabe sinnvolles miteinander zu verbinden. Stundenlanges debuggen eines Assemblerprogrammierers auf der Suche nach dem einem, falschen, Bit; das liegt mir nicht.
mfg
BerndJ
Hallo BerndJ,
also das kann ichmir auch einfacher machen, da ja IPS das alles schon ins log schreibt. Also einfach das ganze mit einem Grep auf den Fehler in eine Datei umgeleitet und schon habe ich alle Fehlermeldungen vorliegen.
Mal schauen, vielleicht mache ich das heute abend mal fuer den Monat Februar bei mir…
Hallo Bernd,
bei mir treten diese sporadischen Ausfälle der One-Wire Sensoren auch auf.
Allerdings bin ich davon überzeugt, dass es kein Kabelproblem ist.
Was mich so sicher macht? Mit IPS-V1 gab es keinen einzigen Ausfall. Zumindest habe ich nie einen bemerkt.
Nach einiger Suche bin ziemlich sicher auch die Ursache der Probleme gefunden zu haben. IPS-2 verbraucht mehr Rechnerressourcen als IPS-1. Dadurch kommt es gelegentlich zu 100% Systemauslastung mit daraus resultierenden Timeouts. Setze ich den IPS-Rechner etwas unter Stress, kommen dann sehr schnell die Fehlermeldungen der One-Wire Sensoren.
Ich möchte das ein klitzekleinwenig bekräftigen indem ich folgende feststellung gemacht habe:
nach einem (beispielsweise) rechner-kaltneustartkommt es schon mal vor das ips mit dem tmex nicht kommunizieren kann.
findet ihn einfach nicht. aber wenn ich das gleich versuche und dann den iViewer starte, der findet alles und umgehend.
danach iViewer schliessen und nun kann auch IPS den TMEX wieder finden/aktivieren!
Also ich denke vom Gefühl her, kann der iViewer viel besser mit dem Treiber umgehen als IPS
(möchte aber nichts unterstellen, aber so die bisjetzigen persönlichen erfahrungen!)
Hallo Forum,
ich habe ebenfalls die Erfahrung gemacht, dass in der V2 das 1-Wire System nahezu unbrauchbar geworden ist.
Es ist z.B. nicht möglich die 4 Kanäle eines einzelnen DS2450 (A/D-Wandler) im Sekundentakt auszulesen.
Das war in der V1 überhaupt kein Problem. In der V2 gehen dabei ständig Daten verloren.
Gruß
HJH
Hallo HJH,
dazu waere es wuenschenswert zu wissen, unter welchen Bedingungen Du das festgestellt hast. Ich meine also folgende Zustaende:
IPS laeuft als Dienst (logisch)
keine Console offen
Console offen, aber keine Baumstruktur
Console offen, Baumstruktur offen
Wie das ganze mit dem Designer aussieht, weiss ich leider nicht, da ich diesen nicht verwende.
Hallo Uwe,
die Console läuft bei mir als Kontrollzentrum ständig. Um ein paar Variablen nachzusehen entwerfe ich nicht extra eine Designer/Dashboard Anwendung.
Also: Console läuft in der Baumstruktur-Ansicht, kein Designer.
Gruß
HJH
Hi Torro,
ich hoffe Du klärst uns Unwissende auf, wie das geht.
Mittlerweile hat die Diskussion sich in eine neue Richtung entwickelt, Klasse Community.
Hilfreich wär dann ´ne Multigrafik zum untermauern dieser These: Systemauslastung in Verbindung mit der Fehlerquote.
Frage?
Als Anwendungstip zwischendurch, kann man das minimieren indem man die Werte mit Pausen nacheinander ausliest?
mfg
BerndJ
Die brauch ich nicht. Das ist Verhalten ist zuverlässig nachvollziehbar.
Die einzige Schwierigkeit liegt darin, nicht gleich zuviel Last zu erzeugen, sonst setzt IPS komplett aus.
Bei Temperatursensoren ist ein fehlender Messwert ja auch nicht wirklich problematisch. Richtig ärgerlich ist, dass das TMEX-Modul bei zwei gleichzeitig hängenden Timern vollständig blockiert.
Man kann das in der Timer-Übersicht gut beobachten. Zur der Abfrage wird das Intervall eines Sensors auf 300 gesetzt. Wenn zwei Sensoren dauerhaft ein Intervall 300 haben, muss das TMEX-Modul zurückgesetzt werden.
Hallo BerndJ,
nein, das Abfrageintervall gilt für alle aktivierten Kanäle. Abgesehen davon liegt es ja in meiner Absicht alle Kanäle möglichst of auszulesen, um Spitzenwerte zu erfassen.
Gruß
HJH
Hallo robi,
also ich habe 47 „strong-accessing“ Warnungen (sind keine Fehler) innerhalb von 8 Tagen. Das sehe ich bei meinem Netz also voellig unrelevant an.
Bei Temperatursensoren ist ein fehlender Messwert ja auch nicht wirklich problematisch. Richtig ärgerlich ist, dass das TMEX-Modul bei zwei gleichzeitig hängenden Timern vollständig blockiert.
Man kann das in der Timer-Übersicht gut beobachten. Zur der Abfrage wird das Intervall eines Sensors auf 300 gesetzt. Wenn zwei Sensoren dauerhaft ein Intervall 300 haben, muss das TMEX-Modul zurückgesetzt werden.
das verstehe ich jetzt nicht. 300 sind doch 5 Minuten? Wenn man weniger ansetzt, passiert das wohl nicht?
Hallo BerndJ,
ist aber Off Topic 
linux:/var/log/ips/grep strong * > anzahl
linux:/var/log/ips/o anzahl
anzahl lines 1-30/47 63%
also vorher natuerlich die betreffenden Log Files auf ein Linux System kopiert…
Hallo Hans-Joerg,
auf dem Rechner direkt, sicherlich, oder?
Dann mach mal folgendes:
ips Dienst stoppen
starte den Taskmanager
ips Dienst starten
Console starten
Baumansicht starten
und dabei immer schoen Deine Systemlast beobachten, dann weisst Du auch, wo Dein Problem ist. So habe ich es bei mir zumindest ausgemacht.
Nein, die Intervalle im Timer-Informationsfenster sind in Millisekunden angegeben. 200 ms scheint die Wartezeit von IPS für eine One-Wire Abfrage zu sein. Da liess mich entweder meine Erinnerung im Stich oder das Intervall wurde inzwischen verkürzt.
Vor einigen Versionen wurden die Einträge der Timer-Übersicht noch automatisch aktualisiert. Da konnte man gut beobachten wie das Intervall beim Auslesen verändert wird.
Hallo Robert,
jetzt verstehe ich, was Du meintest.
steiner hatte geschrieben, dass sie in Bezug auf den 2408 noch etwas gemacht haben, dass dort das Procedere schneller ist. Ansonsten weiss ich nur, dass die V2 anders arbeitet wie die V1. Bei dieser wurden Warnungen gar nicht „bekannt“ gegeben.