Hohe CPU-Auslastung bei andauernder Abfrage

[Furtbichler]

Hey Leute. Es funktioniert ja, so wie er es gemacht hat.

So ein kleiner Ringpuffer ist wirklich zu empfehlen. Ich verwende z.B. einen Ringpuffer mit 2-Tupeln: Das erste Byte ist eine ID (eine fortlaufende Nummer 0-255) und der zweite Wert der Messwert. Ich lese immer den ganzen Ringpuffer und merke mir die letzten X IDs. X ist dabei die Ringpuffergröße. Nun prüfe ich, ob ich die ID schon gelesen habe und bekomme dadurch nur die neuesten Messwerte zu Gesicht.

So kann man mit dem Ringpuffer, seiner Größe und der Abtastrate so rumspielen, das eine skalierbare Lösung dabei herauskommt, die man dann individuell an den IPC und die Umgebung anpassen kann. Es läuft ja vielleicht eine HMI (GUI) oder ein MES-Interface oder noch andere Dinge zusätzlich. Und 'Ja', es gibt IPC, auf denen AV-Scanner laufen.

Ich habe mit dem Verfahren mehr als 5000 Messwerte pro Sekunde in meine Delphi-Anwendung geschaufelt, ohne das die CPU großartig gezuckt hat. Das war zwar nicht in Echtzeit, aber 100ms (oder 150ms k.A) reichen, um die Daten in quasi Echtzeit grafisch anzuzeigen und in einer DB abzulegen. Die war allerdings auf einem anderen Rechner

[ameise]

Guten Morgen,

@hathor: mit deiner Delay Procedure bekomme ich einen Integerüberlauf mit der anderen Procedure aus der CodeLib habe ich weiterhin eine Auslastung von 100%. Also von der Auslastung komm ich nicht runter. Ich habe mir jetzt selbst eine Procedure geschrieben mit der ich genauer als in Millisekunden warten kann und muss somit zumindestens nicht andauernd das Netzwerk belasten. Klappt erstaunlich gut.

Code:

procedure warten(const zeit_ms:double);
var
  start,akt,freq: Int64;
begin
  QueryPerformanceFrequency(freq);
  QueryPerformanceCounter(start);
  akt:=start;
  while (akt-start)*1000/freq<zeit_ms do begin
    application.ProcessMessages;
    QueryPerformanceCounter(akt);
  end;
end;

@Helmi: ich habe leider keine Möglichkeit das SPS Programm zu ändern.

Also ich habe auch einen acht Kern Prozessor eingebaut, deswegen liegt die CPU Auslastung insgesamt für das Auslesen bei 25%. Auf weiteren zwei Kernen werte ich die Daten noch etwas aus und dann bleiben immer noch vier für den ganzen Rest. Der PC ist auch nur für die Aufgabe zuständig, ob das alles dauerhaft konstant funktioniert muss ich mal sehen.

[hathor]

Zitat von ameise:

Guten Morgen,

@hathor: mit deiner Delay Procedure bekomme ich einen Integerüberlauf

Ändere INT in INT64.

[Medium]

Und das Application.ProcessMessages würde ich da dringend rausschmeissen, wenn es denn auf diese Weise sein soll. Was sprach eigentlich nun gegen ein einfaches Sleep(1)? Letztlich muss ja kein bestimmer Takt exakt eingehalten werden, sondern hier geht es lediglich um "schnell genug". Daher sollte diese einfache Methode völlig ausreichend sein.
Fraglich ist nachher aber wie zuvor, ob der Kommunikationsweg da überhaupt mit spielt. Wenn es via Ethernet (egal welches Protokoll nun) läuft, dann wird's schon sehr sehr eng. Je nach dem wie wichtig es dann ist wirklich lückenlos zu sein, wäre es dann wohl eh nötig den Entwickler des SPS Programms anzuahuen diese Schnittstelle "gefälliger" zu gestalten.

[himitsu]

Zitat von hathor:

Wer im ms-Bereich programmiert, muss folgende Seite und WINDOWS gut kennen:

Wobei Now und TTimer nicht im Sekundenbereich arbeiten.

Das arbeitet wie bei GetTickCount aktuell so mit rund 16 ms.