Messdaten Reihe

[AUGE_OHR]

hi,

ich habe doch eine Temperatur Kontrolle mit Xbase++/WMI für unseren HP Server geschrieben.

ab dem "Grenzwert" werden nun die anfallenden Messdaten interessant und ich will die in ein
Logfile schreiben. Da ich aber sehr viele Daten haben könnte (2/sec) muss ich die "komprimieren"

beim "erfassen" denke ich an ein Array wo ich ja durchaus 86400 Elemente erzeugen könnte.
Jedes Element wäre dann 1sec zuzuordnen.

nun könnte man ja einfach das ganze Array abspeichern ... aber es sind ja nur die Daten
interessant welche über den "Grenzwerten" liegen ...

nun läuft aber das ganze "fast live" d.h. ich habe nicht "viel Zeit" (1-5sec einstellbar) um was
zu machen den sonst kommen schon die nächsten Daten an.

also was nun machen :
a.) 86400 Elemente anlegen und die "live" auffüllen und "später" auswerten
b.) Array "dynamisch" als FIFO (first-in-first-out) mit mehreren Threads (lesen,schreiben,auswerten)

mindestens 1 Thread werde ich wohl einsetzten müssen um zwischendurch ein "Backup" des
Arrays zu machen (möglicher Strom Ausfall) ... hm ...

... oder hat jemand vielleicht eine "ganz andere" Idee wie ich ein vernünftiges Logfile bekomme?

[brandelh]

Hi,

soll der Server noch was anderes machen als diese Werte lesen ?

Auf den ersten Blick würde ich sagen, dass 2 Werte je Sekunde viel zu viel sind.
Die Temperatur reagiert doch viel träger ...
Dann würde ich auch kein Array mit mehreren Threads vollschreiben, denn damit wird kostbarer Arbeitsspeicher verbraucht.
Ich würde ein KLEINES Progrogramm ohne GUI (braucht weniger Speicher) schreiben,
das die Werte z.B. im 5 Sekunden Takt ermittelt (besser 10 bis 20 Sekunden) und sofort in eine DBF (kein INDEX, nur anhängen) schreibt.
Hierbei dann beachten, dass die maximale Größe einer DBF nicht überschritten wird ...
Der Schreibzugriff in eine exclusive Datei ist sehr schnell und fällt nicht ins Gewicht.
Der Rest der Zeit SLEEP schläft das Programm und verbraucht somit keine CPU Zeit und nur wenig Resourcen.
Apache und andere Serverprogramme schreiben in Textdateien ...

[AUGE_OHR]

soll der Server noch was anderes machen als diese Werte lesen ?

wieso das ist doch bei einem xGHz PC kein Problem. ich liege da bei 1-4 CPU%

Auf den ersten Blick würde ich sagen, dass 2 Werte je Sekunde viel zu viel sind.
Die Temperatur reagiert doch viel träger ...

das kommt wohl auf den CPU Kühler an ...
nach 2sec ist evtl. die CPU schon "durchgebrannt" wenn der Kühler nicht richtig sitzt.

auch bekommt man bei längerer Zeitspanne nicht mit ob die CPU "trogglt" weil zu heiss wie
ich es in den letzten Tagen bei vielen CoreDuo2 gesehen habe ... und die Jungs wundern sich
das ihre Kisten nicht richtig laufen ... hihi

Dann würde ich auch kein Array mit mehreren Threads vollschreiben, denn damit wird kostbarer Arbeitsspeicher verbraucht.

86400 Elemente = 86Kb ... da rührt sich "nichts" in der Taskmanager Anzeige des RAM

Ich würde ein KLEINES Progrogramm ohne GUI (braucht weniger Speicher) schreiben,
das die Werte z.B. im 5 Sekunden Takt ermittelt (besser 10 bis 20 Sekunden) und sofort in eine DBF (kein INDEX, nur anhängen) schreibt.
...
Der Schreibzugriff in eine exclusive Datei ist sehr schnell und fällt nicht ins Gewicht.

leider ist gerade ein APPEND BLANK / REPLACE "so langsam" das dass genau nicht geht
und ich deshalb auf die Frage kam. Wenn man jede Sekunde ein APPEND macht geht der Server
schon ganz schön in die Knie ... deshalb die Idee mit dem Array ... und "komprimieren"

Wie du schon richtig sagt ist der Server die meiste Zeit am "schlafen" und die Temperatur
"konstant". Diese Wert sind aber uninteressant, nur die "Ausreisser" sind von Interesse.

auch denke ich nicht das ich jeden "einzelnen" Wert benötige sondern die "Reihe"

47 47 47 48 49 50 51 52 53 52 51 50 49 48 47 47 47

ab 48 bis 53 und zurück auf 48 -> +1 +2 +3 +4 +5 +6 -> 47+1+1+1+1+1+1 -> 47;1.0;53

Ich brauche also nicht unbedingt "alle" Messwert sondern nur eine "Zusammenfassung" der
wichtigen Fakten wie 47;1.0;53 ... nur wie bekäme man so was aus dem 86400 Array "errechnet" ?
(p.s. nicht mit Excel ...)

[brandelh]

nach 2sec ist evtl. die CPU schon "durchgebrannt" wenn der Kühler nicht richtig sitzt.

Der Rechner dürfte in diesem Falle nicht booten, da die CPU SOFORT zu heiß wäre,
aber durchbrennen dürften die Prozessoren nicht mehr

AUF KEINEN FALL wird dein Programm schon aktiv sein um daran irgendetwas zu verbessern

Wenn append blank zu langsam ist (bei exclusiver Öffnung auch ?), dann nimm eine Textdatei und puffere einige Einträge (10) in einer Textvariablen zwischen (chr(13)+chr(10) ) nicht vergessen und schreibe diese dann Blockweise weg.
Ob set alternate to ... oder fopen / fwrite besser sind weiß ich nicht ...

[AUGE_OHR]

AUF KEINEN FALL wird dein Programm schon aktiv sein um daran irgendetwas zu verbessern

YUP ... wenn Rauch aus dem Computer kommt ...

Wenn append blank zu langsam ist (bei exclusiver Öffnung auch ?), dann nimm eine Textdatei und puffere einige Einträge (10) in einer Textvariablen zwischen (chr(13)+chr(10) ) nicht vergessen und schreibe diese dann Blockweise weg.
Ob set alternate to ... oder fopen / fwrite besser sind weiß ich nicht ...

blockweise ist gut, "set alternate to" wird bei einem Dienst wohl nicht gehen (oder doch mit CONSOLE OFF ?)

aber nochmal zum "Block" ... 47 47 47 47 47 47 47 47 47 47 47 47 ... das bringt es doch nicht ...
alles was über den "Grenzwerte" liegt ist klar, aber ich würde gerne die "Entwicklung" sehen wie es
dahin gekommen ist und wie oft und wie lange ... also eher wie eine Excel Auswertung.

ich hätte also gerne etwas "Intelligenz" ... ich habe ja Daten im Array ...

Code: Alles auswählen

nElement := INT(SECONDS())
nDurchschnitt_Temp_letzten_100_Daten := Summe(aArray[ nElement-100 ] ,;
                                              aArray[ nElement ]      ) / 100

DO CASE
     CASE NeuMesswert > nDurchschnitt_Temp_letzten_100_Daten + nToleranze
             Das_ist_ein_interessanter_wert(NeuMesswert)
             recursive_weiter()

klar das ist Pseudo Code, aber wie müsste die Function Summe() mit AEVAL() aussehen ?

Code: Alles auswählen

bBlock := {|x,i| nSum := nSum+x[i]}
AEval(aArray,bBlock,nElement-100,nElement)

[Dieter]

Hallo Jimmy,

ich würde die Temperaturmessdatenauswertung wie folgt machen:

Im Main-Programm einen neuen Thread starten, der genau eine Stunde lang alle 2 sec die Temperaturdaten in ein Array1 schreibt. Nach der ersten Stunde werden die Daten dann in das Array2 geschrieben. In der Zwischenzeit wertet die main() das Array1 aus und schreibt die wichtigsten Daten in eine DBF weg. Nach der zweiten Stunde werden die Daten wieder in Array1 geschrieben usw……
Pro Stunde würde ich maxTemp, minTem, und verschiedene fastTemp in die DBF speichern. FastTemp2 wäre z.B. der höchste Temperaturanstieg pro Zeiteinheit 2 sec.
FastTemp60 wäre z.B. der höchste Temperaturanstieg pro Zeiteinheit 60 sec.
Ein weiteres Programm könnte dann die DBF auswerten und die Daten in Kurvenform im Tagesverlauf (Zeitachse 24h) darstellen.

[brandelh]

Hallo Jimmy,

ich würde die Aufgaben klar verteilen !

1. Der Daten Sammelthread:

prüft in einer festgelegten Zeitspanne die Temperatur.
-> wenn diese den Grenzwert überschreitet, speicherst du die ZEIT (Time oder Seconds ?) UND die Temperatur.
-> die absolute Temperatur ist sehr wichtig ! 10° Steigerung sind kein Problem, wenn sie wegen einer plötzlichen
Belastung dennoch im grünen Bereich bleiben Falls du später aber den Schwellwert änderst, wären die Daten
nicht mehr vergleichbar.

2. Ein Auswertungsprogramm kann die Daten dann einlesen, umwandeln etc, denn dieses hat ja Zeit

[AUGE_OHR]

hi,

ich würde die Aufgaben klar verteilen !

Ja ich sehe schon an euren Vorschlägen das ich wohl nicht zuviel auf einmal machen sollte

2. Ein Auswertungsprogramm kann die Daten dann einlesen, umwandeln etc, denn dieses hat ja Zeit

Zeit zum auswerten oder das Auswertungsprogramm ?

ich denke gerade : wie soll man 86400 Daten auf einem 1024 Bildschirm darstellen ?

... XBPPS_MODE_HIGH_TXT_PRECISION / oPS:setViewPort( {0,0,1024,768} )

ich hab mal weiter mit dem 86400 Array getestet und eine DBF mit 7 Records angelegt.
mit GOTO(DOW(DATE())) wird er nun auf einen der 7 Records positioniert.

Das Array wandel ich nun mit Var2Bin(aArray) in einen String um und kann den dann im Memo
( FPT) abspeichern und mit Bin2Var(MyDBF->LogArray) wieder ein Array draus machen.
Das leere 2-Dim Array belegt dabei ca. 2.3MB und mit 2stelligen Werten gefüllt ca. 3.5MB *7=24,5

Das ist aber nur das "interne" Workfile für das gesamte Array. Für die "Aussreisser" gehe ich
nun so ähnlich vor wie ihr vorgeschlagen habt, aber "dynamisch".

Code: Alles auswählen

METHOD HP_Anzeige:Durchschnitt(nNo,xValue,nTime)
LOCAL nSum  := 0
LOCAL nRet  := 0
LOCAL bBlock

   IF nNo == 1
      ::aTime[nTime,1] := xValue
      bBlock := {|x,i| nSum := nSum+x[1] }
      AEVAL(::aTime,bBlock,nTime-100,100)
      nRet   := nSum/100

      ::nQuer1 := nRet
   ELSE
      ::aTime[nTime,2] := xValue
      bBlock := {|x,i| nSum := nSum+x[2] }
      AEVAL(::aTime,bBlock,nTime-100,100)
      nRet   := nSum/100

      ::nQuer2 := nRet
   ENDIF

RETURN nRet

leider ist der Codeblock nicht "perfekt" da es Elemente mit 0 gibt ...

wie müsste man bBlock erweitern damit er "leere" Elemente auslässt ?
ich verwende ja auch nSum/100 was dann nicht ganz richtig ist ...

wieso überhaupt "leere" Elemente ? ich denke es liegt am 100/100sec Timing ... regelmässig
gibt es 0 und zählt dann weiter. wenn ich ihm 99/100 gebe werden die Abstände etwas grösser.
also auch da ist noch ein wenig "Tuning" nötig.

Durchschnitt()+Toleranz ist jetzt die erste Stufe wo das eigentliche Logbuch eingreift. Auch
hier wird erstmal per AADD() ein Array mit Informationen gefüttert bis sich wieder "konstante"
Werte einstellen. Dann erst wird ein Thread aktiviert der das Array "bearbeitet".

Frage : mit AClone() wird doch eine "physikalische" Kopie angelegt ? Damit kann ich das "original"
doch "löschen", oder ?

soweit scheint alles auch zu laufen ... RAM ist genügend vorhanden und das Backup des Array
(3.5MB) alle 999sec beeindruckt die Server CPU überhaupt nicht (HD / Cache ?)

... damit wird er (hoffentlich) bis 23:59 laufen, den dann wird er bei

Code: Alles auswählen

AEVAL(::aTime,bBlock,nTime-100,100)

versagen und abstürzen ... aber bis dahin werden "wir" doch noch eine Lösung finden

[Lewi]

Hi Jimmy,
ich würde nur Temperaturänderungen erfassen. In Deinem Fall ein Abgleich mit dem letzten Array-Element. Meines Erachtens wäre dies in der Sache auch übersichtlicher.

Gruß, Olaf

[AUGE_OHR]

ich würde nur Temperaturänderungen erfassen. In Deinem Fall ein Abgleich mit dem letzten Array-Element. Meines Erachtens wäre dies in der Sache auch übersichtlicher.

ich habe ja jetzt "erfassen" und "auswerten" getrennt.
"erfassen" tue ich immer noch "alles" im Array ... kostet ja "nur" RAM (WMI SELECT from < 1CPU%)
bei der "Auswertung" denke ich sollte ich gar nicht mehr so weit ins Detail gehen, obwohl ich jeden
Messpunkt hätte.

was ich allerdings gerne noch optimieren würde, wäre den Codeblock :

Code: Alles auswählen

LOCAL aSize := oMain:drawingArea:currentsize()
...
nLen := LEN(aTime[1]) // 2-dim
FOR j := 1 TO 2
   bBlock  := {|x,i| aPoints := {i/86400*aSize[1],x[j]*aSize[2]/1000},;
                  GraMarker(oPS ,aPoints)                          }
   AEVAL(aTime,bBlock,1,nLen)
NEXT

das ganze ist jetzt für eine 0-100% = Grad Lösung in der Y-Achse, aber ich nutzte die ja nicht komplett.
alles was unter 40% liegt und über 80% liegt ist ja uninteressant, deshalb würde ich gerne nur
den 40%-80% in der Y-Achse benutzen und auf aSize[2] "zoomen" ...

... oder muss ich per :setViewPort() den 40-80% Bereich einstellen und das "zoomen" ?

[AUGE_OHR]

... oder muss ich per :setViewPort() den 40-80% Bereich einstellen und das "zoomen" ?

so den 40-80% Bereich hab ich wohl auch im Griff und nun das nächste Problem.

Code: Alles auswählen

CASE nEvent == xbeP_Keyboard .and. mp1 == xbeK_F1
   TONE(1234)
   oDlg:hide()
   nStart := 60*60*1
   nEnde  := 60*60*13
   nSegId := 0
   oDlg:show()
   SetAppFocus( oDlg )

damit habe ich einen "zoom" von 01:00 - 13:00 und das funktioniert, aber nun kommt das

Code: Alles auswählen

oDlg:drawingArea:lbDown := {| aPos, uNIL, oSelf | Zoomit(1,aPos,oDlg,@lMouse,@nStart,@nEnde,@nSegId) }
oDlg:drawingArea:lbUp   := {| aPos, uNIL, oSelf | Zoomit(2,aPos,oDlg,@lMouse,@nStart,@nEnde,@nSegId) }
...
oDlg:drawingArea:paint := {|| DrawGraphic(oPS, @nSegId, aTime,oDlg,nStart,nEnde) }
...

PROCEDURE Zoomit(nNo,aPos,oDlg,lMouse,nStart,nEnde,nSegId)

STATIC nWert1  := 0
STATIC nWert2  := 0

   DO CASE
      CASE nNo  == 1
         IF lMouse
         ELSE
            lMouse := .T.
            nWert1 := INT(86400/oDlg:currentsize()[1]*aPos[1])
            TONE(1234)
         ENDIF

      CASE nNo  == 2
         IF lMouse
            nWert2  := INT(86400/oDlg:currentsize()[1]*aPos[1])
            IF nWert1 = nWert2
               lMouse := .F.
            ELSEIF nWert1 > nWert2
               lMouse := .F.
            ELSE
               IF lMouse
                  oDlg:hide()
                  lMouse := .F.
                  nSegId := 0
                  nStart := nWert1
                  nEnde  := nWert2
                  oDlg:show()
                  MSGBOX("nStart"+STR(nStart)+" nEnde"+STR(nEnde))
                  SetAppFocus(oDlg)
*                 PostAppEvent(xbeP_Paint,,,oDlg:drawingArea)
               ENDIF
            ENDIF
         ENDIF
   ENDCASE
RETURN

also ich clicke auf die :drawingArea, gehe auf die neue Position und lasse die Taste los.
Es funktioniert ... aber nicht immer ?! manchmal ist die Grafik dann "leer" ...

das xbeP_Paint wird immer durch ein oDlg:hide() / oDlg:show() sodas eine PostAppEvent(xbeP_Paint...)
nicht zusätzlich notwendig "erscheint". Die Positionen werden "umgerechnet" und die Ausgabe in
der Msgbox() sieht gut aus ... trotzdem nicht immer eine Grafik ...

vielleicht ist das :lbDown / :lbUp nicht das "richtige" dafür ? ist :dblClick hier vielleicht "besser" ?

[AUGE_OHR]

hi,

die "Werte" scheinen wohl richtig zu sein, aber in der "Umrechnung" stimmt was noch nicht.

Code: Alles auswählen

  /*
   * Der Callback Codeblock muß bei :drawingArea
   * eingetragen werden, da die Grafik in ihr
   * angezeigt wird. Die Variable nSegId speichert
   * die Id des grafischen Segments, welches zur
   * Ausgabe verwendet wird. Das Segment wird
   * beim ersten Aufruf der Prozedur DrawGraphic()
   * erzeugt.
   */
   oDlg:drawingArea:paint := {|| DrawGraphic(oPS, @nSegId, aTime,oDlg,nStart,nEnde) }

...

PROCEDURE DrawGraphic( oPS, nSegId , aTime, oMain,nStart,nEnde)
LOCAL aSize       := oMain:drawingArea:currentsize()
LOCAL nMesswert   := ROUND(nEnde-nStart,0)+1
LOCAL nStunden    := nMesswert/60/60
LOCAL nScStart    := ROUND(nStart/60/60,0)
LOCAL nScWeite    := 86400/nMesswert

   //
   // Y-Achse Line
   //
   aLast := {0,(4.5*10*aSize[2]/1000*2.5)}
   FOR i := 45 TO 80 STEP 5
      graStringAt( oPS, aLast, LTRIM(STR(i*1)),oFont )
      aPoints := {aSize[1],((i*10-400)*aSize[2]/1000*2.5)}
      GraLine(oPS, aLast, aPoints)
      aLast := {0,aPoints[2]+((100/2)*aSize[2]/1000*2.5)}
   NEXT
   //
   // X-Achse Line
   //
   i := 1
   aLast := {aSize[1]/nStunden*1,0}
   FOR i := nScStart TO nStunden
      graStringAt( oPS, aLast, LTRIM(STR(i)),oFont )
      aPoints := {aSize[1]/nStunden*i,aSize[2]}
      GraLine(oPS, aLast, aPoints)
      aLast := {aPoints[1]+(aSize[1]/nStunden*1),0}
   NEXT

   FOR j := 1 TO 2
      IF J = 1
         aAttr[ GRA_AM_COLOR]     :=  GRA_CLR_GREEN
         aAttr[ GRA_AM_BACKCOLOR] :=  GRA_CLR_BACKGROUND
      ELSE
         aAttr[ GRA_AM_COLOR]     :=  GRA_CLR_PINK
         aAttr[ GRA_AM_BACKCOLOR] :=  GRA_CLR_BACKGROUND
      ENDIF
      GraSetAttrMarker( oPS, aAttr )

*      kMax  := LEN(aTime)
*      k     := 0
*      FOR k := 1 TO kMax STEP 2
*         aPoints := {k/nMesswert*aSize[1],(aTime[k,j]-400)*aSize[2]/1000}
*         GraMarker(oPS ,aPoints)
*      NEXT

*     bBlock  := {|x,i| aPoints := {i*nScWeite/nMesswert*aSize[1]  ,;

      bBlock  := {|x,i| aPoints := {i         /nMesswert*aSize[1]  ,;
      IF(x[j]<400,(1*aSize[2]/1000),((x[j]-400)*aSize[2]/1000)*2.5)},;
                        GraMarker(oPS ,aPoints)        }

      AEVAL(aTime,bBlock,nStart,nMesswert)
   NEXT

"sieht" jemand wo ich den Denkfehler drin habe ?

bei 1Std oder 2Std kommt "nichts", bei 3Std erhalte ich das :

Gitter.JPG (61.67 KiB) 7464 mal betrachtet

und ab 4Std erhalte ich dann ein "richtiges" Gitter.

achso das "zoom" geht nur bei kleinern Bereichen ... im "hinteren" Teil scheine ich gar nichts mehr
zu bekommen ... also irgendwie ist da noch der Wurm drin ...

[AUGE_OHR]

hi,

ok nun habe ich es soweit das ich wohl auch ein kleines Demo von dem "Auswertungs" Programm
machen kann. Auch das "zoom++" klappt und ich bin auch schon beim "zoom--" ...

ich habe es ja für 86400 2-Dim Elemente ausgelegt, klar das die einige Zeit brauchen auch bei
einem AEval(), aber dann das "zoom++" geht schnell (klar sind ja dann auch weniger Elemente)

ich nutze nun den :Paint Callback der :drawingArea, aber ich könnte ja auch eine XbpStatic
nehmen ... :drawingArea:Paint "ruft" nun automatisch wenn es den Focus , beim Fensterwechsel,
bekommt den Codeblock auf ... täte ein XbpStatic das auch "automatisch" ?

[AUGE_OHR]

hi,

ich habe da oThread:setInterval() getested und prompt geht das in die Hose.

ExecQuery.jpg (18.6 KiB) 7407 mal betrachtet

dagegen funktioniert aber der 4th Parameter nTimeout von AppEvent() mit dem selben Code
welche zwar auch "handles" braucht aber die wieder "freigibt".

Code: Alles auswählen

//
// das crash irgendwann ...
//
*  oThread:start({||oDlg:Checkit()})
*  oThread:setInterval(nTimeout)

   nEvent := xbe_None
   DO WHILE !lExit
      nEvent := AppEvent ( @mp1, @mp2, @oXbp, nTimeout )
      DO CASE
//
// das funktioniert tagelang ...
//
         CASE nEvent == xbe_None
            oDlg:Checkit()

Das :setInterval() scheint bei < 100/100sec den Speicher nicht wieder frei zu geben ... und dann knallt es irgendwann.

[Martin Altmann]

Hallo Jimmy,
hast Du den Hinweis in der Hilfe zu :setInterval gelesen

Der Thread bleibt aktiv bis das Zeitintervall wieder auf NIL gesetzt wird. Erst dann wird der Thread beendet.

Du startest also jedes Mal einen neuen Thread, ohne den alten zu beenden.

Viele Grüße,
Martin

[AUGE_OHR]

Hallo Jimmy,
hast Du den Hinweis in der Hilfe zu :setInterval gelesen

Der Thread bleibt aktiv bis das Zeitintervall wieder auf NIL gesetzt wird. Erst dann wird der Thread beendet.

Du startest also jedes Mal einen neuen Thread, ohne den alten zu beenden.

hm ... also wenn de Code durchlaufen ist "soll" der Thread ja noch aktive sein damit :setInterval(100)
ihn überhaupt wieder aufrufen kann ... ist doch "blöde" wenn ich per :setInterval(NIL) erst
"resetten" müsste wenn der den Code durchlaufen hat ... das sollte Xbase++ doch dann "merken"
und "intern" ein NIL setzten wenn es zu "doof" ist zu erkennen das bei :setInterval(100) wieder
der "selbe Thread und Code" gemeint ist ...

ok ich werde es nochmal ausprobieren, danke

p.s. um aber "im" Code oThread:setInterval(NIL) setzen zu können MUSS ich ja oThread als
Parameter übergeben ... das MUSS geht ja gar nicht !

Code: Alles auswählen

oThread:start({||oDlg:Checkit("localhost",oThread)},"localhost",oThread)
oThread:setInterval(nTimeout)

METHOD HP_Anzeige:Checkit(strComputer,oThread)
...
oThread:setInterval(NIL)
RETURN self

ich den Code ausprobiert und es passier was ich mir dachte :
oThread:setInterval(NIL) "terminiert" eine "Wiederholung" d.h. dann wird der Thread nur 1x ausgeführt.

[Martin Altmann]

Hallo Jimmy,
ich verstehe Dein Problem nicht wirklich... glaube ich zumindest
Warum machst Du nicht einen Thread, der in einer "Endlos-"Schleife (Abbruchbedingung von aussen setzbar) die Temperatur misst und dann die von Dir gewünschte Zeit schläft, Temperatur misst, schläft, ...?

Viele Grüße,
Martin

[AUGE_OHR]

Warum machst Du nicht einen Thread, der in einer "Endlos-"Schleife (Abbruchbedingung von aussen setzbar) die Temperatur misst und dann die von Dir gewünschte Zeit schläft, Temperatur misst, schläft, ...?

mache ich doch ...
die Frage ist nur ob man mit :setInterval(nTimeout) oder mit AppEvent(,,,4th Parameter) verwendet, wobei das :setInterval(nTimeout) ja wohl nicht zu gehen scheint.

[Martin Altmann]

Hallo Jimmy,
bei meinem Vorschlag weder - noch
Wozu auch
Mit :setIntervall() startest Du immer wieder einen neuen Thread(), ohne den alten ordentlich zu beenden!
Mit AppEvent() hat das auch nicht viel zu tun, da es ja nicht in einem eigenen Thread abläuft.
Schau Dir mal das Beispiel in der Onlinehilfe an (oder den Beitrag hier von mir zu einem entsprechenden Problem von Manfred). Dann weißt Du, wie ich das meine: http://www.xbaseforum.de/viewtopic.php?f=20&t=3349
Du warst in dem Beitrag auch rege beteiligt...

Viele Grüße,
Martin

[AUGE_OHR]

Mit :setIntervall() startest Du immer wieder einen neuen Thread(), ohne den alten ordentlich zu beenden!

das ist IMHO hier weder notwendig noch funktioniert es hier. Es könnte mit activeX und WMI zu tun haben

Mit AppEvent() hat das auch nicht viel zu tun, da es ja nicht in einem eigenen Thread abläuft.

es geht doch nur um das "timeout" und das funktioniert ja im Prinzip wie ein :setIntervall()

ich fürchte das genau ein Thread nicht mit activeX geht. ob das an WMI liegt muss ich noch
rausbekommen, aber ich hatte solche activeX schon mal die mit Xbase++ Thread Probleme
machen (mit einem anderen Compiler funktioniert es ...)

ich denke aber das ich mich mit dem was ich jetzt habe zufrieden geben kann ... es "zeigt" mir
schon das was ich wissen will sodas ich die Kühlung nun "berechnen" können müsste (naja ich
nicht, aber ein Bekannter der was mit Klimatechnik macht)

Die Application macht ja nur für HP Proliant Server Sinn, aber die "Auswertung" könnte man
auch für andere Sache gebrauchen. Ich werde mal die Demo fertig machen und hier reinstellen.

[AUGE_OHR]

hi,

CPU_Graph.JPG (81.1 KiB) 7329 mal betrachtet

die rote Marker ist die CPU, die grünen Marker sind Mainboard und bei den schwarzen liegen beide übereinander.

um ca. 08:00 hab ich 6 zusätzliche Lüfter laufen lassen (was für ein Krach) und gegen 12:30
wieder abgeschaltet und ab 23:00 wieder an.

interessant dabei das die CPU Temperatur, im Leerlauf, unter die vom Mainboard liegt ... wieso ?
"Aussen" Temperatur 26.4 geschlossen mit 6 Lüftern, Tür "offen" 33,8.

den Source dazu, der dynamisch funktioniert, werde ich in die Wissensbasis stellen.

[Rudolf]

Hallo,
hab sowas ähnliches mal gemacht, mit programmierbaren Sensoren. Habe immer nur die Änderungen mit einem Zeitstempel gespeichert. Habe einen einstellbaren Bereich für das Triggern der Schwankung gemacht. Damit war das Schreiben in eine DBF kein Problem. Und da sowieso viel im Cache abläuft, denke ich nicht dass es ein Problem damit geben kann.
Grüsse
Rudolf

[phonix]

wenn ich das richtig verstanden hab ja.
ich hatte für ne chemie firma eine wärme messdaten erfassung für metex
messgeräte mit 8 kanäle,und als das programm fertig war ,hab ich mir so überlegt,wieso hab ich ideot eigendlich nicht nur die änderung erfasst.

du hast doch sicher die möglichkeit uhrzeit und datum zu nehmen,
folglich prüfst du den wert einfach auf ungleich ab ,und wenn eine abweichung da ist trägst du einfach datum und uhrzeit ein in die bank ein.

mit ziemlicher sicherheit wird der prozessor die meiste zeit die gleiche temparatur haben.


entschuldige rudolf du stands ganz unten ,ich hab dich jetzt erst gelesen,
nun lass ich den beitrag drin ,ich bin leider erst auf die idee gekommen als ich fertig war mit dem programm ,musste aber auch die rs232 übetragung unter asm zwischen metex und computer mitprogrammieren.

phonix

[Rudolf]

Hallo,
die einfachsten Lösungen sind immer noch die effizientesten
Grüsse
Rudolf