Hohe CPU-Auslastung bei andauernder Abfrage

[Medium]

Das mit diesem Delay ist in einem Thread aber keine so tolle Idee. Dort ist ein schnödes Sleep schon am rechten Fleck. Diese Delay-Krücke ist ja eigentlich für den Einsatz im VCL-Thread gedacht, wo so Wartedinger imho aber ohnehin nichts verloren haben.

Auch die 50ms-Geschichte: Das gilt für Timer, weil das Message-System von Windows da problematisch wird. Der Scheduler hat damit allerdings nichts zu tun.

Blubbert doch bitte nicht gleich mit Volksweisheiten los, ohne den Anfangsbeitrag gelesen zu haben. Nach Schlagworten abtasten geht oft gut, aber nicht immer


Wenn den Threads eigene Cores zugewiesen sind, und auf dem PC sonst eher wenig passiert, sind 1.5ms Zykluszeit überhaupt kein Problem, auch mit einem Sleep(1) dazwischen sollte das noch gut passen. Einzig der Fall, dass tatsächlich gelesen werden muss ist so eine Sache: Je nach dem wie die Kommunikation läuft, und was mit dem gelesenen Wert passiert, kann (wird) das arg eng. Da wäre eine Art Ringpuffer in der SPS wirklich praktisch.
Angenommen du hast eine Siemens SPS und kommunizierst (z.B. mit der libnodave) via S7-Online bzw. ISO-over-TCP Protokoll, kannst du je nach SPS bis zu 216 Bytes in einem Rutsch auslesen. Dann einfach einen Puffer-DB mit passender Größe, und ein Flag für wenn der Puffer eine Runde gedreht hat. (Puffer in der SPS nicht neu befüllen so lange das Flag ansteht! Ggf. einen zweiten Ringpuffer im Wechsel nehmen, damit auch wirklich nichts verloren geht.) So ein Paket von 200 Bytes ist praktisch genau so schnell gelesen wie ein einzelnes Byte, und man schafft sich auf PC-Seite ein wenig Luft den gelesenen Puffer zu verarbeiten. (Wenn die dennoch nicht langt evtl. über weitere Worker-Threads nachdenken.)

So lange du Einfluss auf das SPS Programm hast (es also PC-freundlich machen kannst), braucht es da eigentlich keine Zusatzhardware. Vor allem nicht, wenn die Lesethreads einen ganz eigenen Kern für sich haben.